5:03 a.m.
Hi guys,
I've uploaded images to my iso domain and I can see the .iso files
under the full path
"/iso-domain/a89acef7-5766-4a61-9176-f7870e4f5989/images/11111111-1111-1111-1111-111111111111/"
with the vdsm:vdsm as the owner but from inside my ovirt-engine the
images don't show up.
Under "Storages" I can see my iso domain is listed as active(green)
and it shows my free space correctly, but if I go to "images' nothing
shows up, under "Data Center" "Default" shows as active as well.
I've
tried putting it into maintenance and then activating which succeeds
and yet my images still don't show.
I uploaded the images as follows....
cd /root/ISOs/
engine-iso-uploader -i ISO upload *
...which completed successfully with no errors.
Any ideas? Will gladly send through whichever logs are required.
Thanks!
Regards.
Neil Wilson.
7:30 a.m.
----- Original Message -----
From: "Neil" <nwilson123(a)gmail.com>
To: users(a)ovirt.org
Sent: Tuesday, October 16, 2012 12:03:21 PM
Subject: [Users] Images not appearing in ISO domain
Hi guys,
I've uploaded images to my iso domain and I can see the .iso files
under the full path
"/iso-domain/a89acef7-5766-4a61-9176-f7870e4f5989/images/11111111-1111-1111-1111-111111111111/"
with the vdsm:vdsm as the owner but from inside my ovirt-engine the
images don't show up.
Under "Storages" I can see my iso domain is listed as active(green)
and it shows my free space correctly, but if I go to "images' nothing
shows up, under "Data Center" "Default" shows as active as well.
I've
tried putting it into maintenance and then activating which succeeds
and yet my images still don't show.
I uploaded the images as follows....
cd /root/ISOs/
engine-iso-uploader -i ISO upload *
Hi Neil,
please print the output of the following commands:
on NFS server:
- ls -la
"/iso-domain/a89acef7-5766-4a61-9176-f7870e4f5989/images/11111111-1111-1111-1111-111111111111/
on host (vds):
- vdsClient -s 0 getIsoList `vdsClient -s 0 getConnectedStoragePoolsList`
...which completed successfully with no errors.
Any ideas? Will gladly send through whichever logs are required.
Thanks!
Regards.
Neil Wilson.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
7:51 a.m.
Hi Haim,
Thanks for coming back to me, below are the outputs...
On Tue, Oct 16, 2012 at 2:30 PM, Haim Ateya <hateya(a)redhat.com> wrote:
please print the output of the following commands:
on NFS server:
- ls -la
"/iso-domain/a89acef7-5766-4a61-9176-f7870e4f5989/images/11111111-1111-1111-1111-111111111111/
[root@engine01 ISOs]# ls -la
"/iso-domain/a89acef7-5766-4a61-9176-f7870e4f5989/images/11111111-1111-1111-1111-111111111111/"
total 11662112
drwxr-xr-x. 2 vdsm vdsm 4096 Oct 16 11:31 .
drwxr-xr-x. 3 vdsm vdsm 4096 Oct 15 18:29 ..
-rw-r-----. 1 vdsm vdsm 4423129088 Oct 16 10:23 CentOS-6.2-x86_64-bin-DVD1.iso
-rw-r-----. 1 vdsm vdsm 3166732288 Oct 16 10:31
microsoft-windows-server2008r2-x86_64.iso
-rw-r-----. 1 vdsm vdsm 1741717504 Oct 16 11:31 symantec-endpoint.iso
-rw-r-----. 1 vdsm vdsm 2610397184 Oct 16 10:37
symantec-systemrecovery-management-2011.iso
on host (vds):
- vdsClient -s 0 getIsoList `vdsClient -s 0 getConnectedStoragePoolsList`
[root@node01 ~]# vdsClient -s 0 getIsoList `vdsClient -s 0
getConnectedStoragePoolsList`
------ ISO list with proper permissions only -------
[root@node01 ~]#
Hope this helps :)
Thanks!
Neil Wilson
8:48 a.m.
Neil,
I suspect that you are having the same issue described in [1].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
On 10/16/2012 08:51 AM, Neil wrote:
Hi Haim,
Thanks for coming back to me, below are the outputs...
On Tue, Oct 16, 2012 at 2:30 PM, Haim Ateya <hateya(a)redhat.com> wrote:
> please print the output of the following commands:
>
> on NFS server:
>
> - ls -la
"/iso-domain/a89acef7-5766-4a61-9176-f7870e4f5989/images/11111111-1111-1111-1111-111111111111/
[root@engine01 ISOs]# ls -la
"/iso-domain/a89acef7-5766-4a61-9176-f7870e4f5989/images/11111111-1111-1111-1111-111111111111/"
total 11662112
drwxr-xr-x. 2 vdsm vdsm 4096 Oct 16 11:31 .
drwxr-xr-x. 3 vdsm vdsm 4096 Oct 15 18:29 ..
-rw-r-----. 1 vdsm vdsm 4423129088 Oct 16 10:23 CentOS-6.2-x86_64-bin-DVD1.iso
-rw-r-----. 1 vdsm vdsm 3166732288 Oct 16 10:31
microsoft-windows-server2008r2-x86_64.iso
-rw-r-----. 1 vdsm vdsm 1741717504 Oct 16 11:31 symantec-endpoint.iso
-rw-r-----. 1 vdsm vdsm 2610397184 Oct 16 10:37
symantec-systemrecovery-management-2011.iso
> on host (vds):
> - vdsClient -s 0 getIsoList `vdsClient -s 0 getConnectedStoragePoolsList`
[root@node01 ~]# vdsClient -s 0 getIsoList `vdsClient -s 0
getConnectedStoragePoolsList`
------ ISO list with proper permissions only -------
[root@node01 ~]#
Hope this helps :)
Thanks!
Neil Wilson
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
9:33 a.m.
Hi Keith,
On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts(a)redhat.com> wrote:
Neil,
I suspect that you are having the same issue described in [1].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
I unfortunately don't have access to view this bug...
"You are not authorized to access bug #858880."
Is there any progress on repairing it, or do you know if there is a
work round in the meantime?
Thanks!
Regards.
Neil Wilson.
9:38 a.m.
On 10/16/2012 10:33 AM, Neil wrote:
Hi Keith,
On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts(a)redhat.com> wrote:
> Neil,
>
> I suspect that you are having the same issue described in [1].
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
I unfortunately don't have access to view this bug...
"You are not authorized to access bug #858880."
Is there any progress on repairing it, or do you know if there is a
work round in the meantime?
AFAIK, there is no work-a-round for the issue and, I
think that the
engine team is having a hard time reproducing the issue.
As a work-a-round you could try 'chmod -R 644 /path/to/iso/domain' .
This gives all files in the ISO domain world read privs. (not what you
want) but I think it will fix the engine issue.
You should know that the ISO uploader uploads files as 36:36 and 640
perms. This is the correct behavior and, based on your previous emails
I can see that your files do appear to match that ACL.
Cheers,
Keith
Thanks!
Regards.
Neil Wilson.
7:15 p.m.
On 10/16/2012 04:38 PM, Keith Robertson wrote:
On 10/16/2012 10:33 AM, Neil wrote:
> Hi Keith,
>
> On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts(a)redhat.com>
> wrote:
>> Neil,
>>
>> I suspect that you are having the same issue described in [1].
>>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
> I unfortunately don't have access to view this bug...
>
> "You are not authorized to access bug #858880."
>
> Is there any progress on repairing it, or do you know if there is a
> work round in the meantime?
AFAIK, there is no work-a-round for the issue and, I think that the
engine team is having a hard time reproducing the issue.
As a work-a-round you could try 'chmod -R 644 /path/to/iso/domain' .
This gives all files in the ISO domain world read privs. (not what you
want) but I think it will fix the engine issue.
You should know that the ISO uploader uploads files as 36:36 and 640
perms. This is the correct behavior and, based on your previous emails
I can see that your files do appear to match that ACL.
the output of vdsClient was an empty list of iso's, so it seems like a
vdsm issue rather than engine?
1:49 a.m.
On Thu, Oct 18, 2012 at 2:15 AM, Itamar Heim <iheim(a)redhat.com> wrote:
On 10/16/2012 04:38 PM, Keith Robertson wrote:
>
> On 10/16/2012 10:33 AM, Neil wrote:
>>
>> Hi Keith,
>>
>> On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts(a)redhat.com>
>> wrote:
>>>
>>> Neil,
>>>
>>> I suspect that you are having the same issue described in [1].
>>>
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>>
>> I unfortunately don't have access to view this bug...
>>
>> "You are not authorized to access bug #858880."
>>
>> Is there any progress on repairing it, or do you know if there is a
>> work round in the meantime?
>
> AFAIK, there is no work-a-round for the issue and, I think that the
> engine team is having a hard time reproducing the issue.
>
> As a work-a-round you could try 'chmod -R 644 /path/to/iso/domain' .
> This gives all files in the ISO domain world read privs. (not what you
> want) but I think it will fix the engine issue.
>
> You should know that the ISO uploader uploads files as 36:36 and 640
> perms. This is the correct behavior and, based on your previous emails
> I can see that your files do appear to match that ACL.
the output of vdsClient was an empty list of iso's, so it seems like a vdsm
issue rather than engine?
Agreed, although to fix it the group name was changed on the engine.
Does VDSM try and match the group name to kvm somewhere along the way?
Neil Wilson.
8:36 a.m.
On 10/17/2012 08:15 PM, Itamar Heim wrote:
On 10/16/2012 04:38 PM, Keith Robertson wrote:
> On 10/16/2012 10:33 AM, Neil wrote:
>> Hi Keith,
>>
>> On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts(a)redhat.com>
>> wrote:
>>> Neil,
>>>
>>> I suspect that you are having the same issue described in [1].
>>>
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>> I unfortunately don't have access to view this bug...
>>
>> "You are not authorized to access bug #858880."
>>
>> Is there any progress on repairing it, or do you know if there is a
>> work round in the meantime?
> AFAIK, there is no work-a-round for the issue and, I think that the
> engine team is having a hard time reproducing the issue.
>
> As a work-a-round you could try 'chmod -R 644 /path/to/iso/domain' .
> This gives all files in the ISO domain world read privs. (not what you
> want) but I think it will fix the engine issue.
>
> You should know that the ISO uploader uploads files as 36:36 and 640
> perms. This is the correct behavior and, based on your previous emails
> I can see that your files do appear to match that ACL.
the output of vdsClient was an empty list of iso's, so it seems like a
vdsm issue rather than engine?
It could be. We have two similar cases now and this
most recent case
appears to have resolved the issue by creating the group 'kvm' on the
'node' (I think).
Based, on that information I suspect that there could be a problem in
VDSM wherein they are attempting to resolve the user/group by name (ie.
vdsm/kvm) and are getting blocked when either that user doesn't exist or
exists with a name != vdsm or kvm. It might be apropos to have a look
at the code and see if/where they're resolving uid/gid 36 and/or vdsm:kvm.
Neil,
- Can you explain where you created the 'kvm' group name? Was it on the
node, oVirt engine, or the NFS server?
- After you created this group did were the permisions on the files in
the ISO domain (vdsm:kvm 0640) or were they (vdsm:kvm 0644 <- notice
world read)
9:30 a.m.
On 10/18/2012 07:06 PM, Keith Robertson wrote:
On 10/17/2012 08:15 PM, Itamar Heim wrote:
> On 10/16/2012 04:38 PM, Keith Robertson wrote:
>> On 10/16/2012 10:33 AM, Neil wrote:
>>> Hi Keith,
>>>
>>> On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts(a)redhat.com>
>>> wrote:
>>>> Neil,
>>>>
>>>> I suspect that you are having the same issue described in [1].
>>>>
>>>>
>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>>> I unfortunately don't have access to view this bug...
>>>
>>> "You are not authorized to access bug #858880."
>>>
>>> Is there any progress on repairing it, or do you know if there is a
>>> work round in the meantime?
>> AFAIK, there is no work-a-round for the issue and, I think that the
>> engine team is having a hard time reproducing the issue.
>>
>> As a work-a-round you could try 'chmod -R 644 /path/to/iso/domain' .
>> This gives all files in the ISO domain world read privs. (not what you
>> want) but I think it will fix the engine issue.
>>
>> You should know that the ISO uploader uploads files as 36:36 and 640
>> perms. This is the correct behavior and, based on your previous emails
>> I can see that your files do appear to match that ACL.
>
> the output of vdsClient was an empty list of iso's, so it seems like a
> vdsm issue rather than engine?
It could be. We have two similar cases now and this most recent case
appears to have resolved the issue by creating the group 'kvm' on the
'node' (I think).
Based, on that information I suspect that there could be a problem in
VDSM wherein they are attempting to resolve the user/group by name (ie.
vdsm/kvm) and are getting blocked when either that user doesn't exist or
exists with a name != vdsm or kvm. It might be apropos to have a look
at the code and see if/where they're resolving uid/gid 36 and/or vdsm:kvm.
Neil,
- Can you explain where you created the 'kvm' group name? Was it on the
node, oVirt engine, or the NFS server?
- After you created this group did were the permisions on the files in
the ISO domain (vdsm:kvm 0640) or were they (vdsm:kvm 0644 <- notice
world read)
If using NFSv4 what is sent through the network is the user/group name,
not the numeric user/group id. In this case the NFS server was sending
the string "vdsm" as the group name. When this arrives to the NFS client
(the hypervisor in this case) it is translated to a numeric group id,
but as there is no "vdsm" group in the client it is translated to the
numeric user id of "nobody".
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
9:52 a.m.
It could be. We have two similar cases now and this most recent
case
appears to have resolved the issue by creating the group 'kvm' on the
'node'
(I think).
Based, on that information I suspect that there could be a problem in VDSM
wherein they are attempting to resolve the user/group by name (ie. vdsm/kvm)
and are getting blocked when either that user doesn't exist or exists with a
name != vdsm or kvm. It might be apropos to have a look at the code and see
if/where they're resolving uid/gid 36 and/or vdsm:kvm.
Neil,
- Can you explain where you created the 'kvm' group name? Was it on the
node, oVirt engine, or the NFS server?
- After you created this group did were the permisions on the files in the
ISO domain (vdsm:kvm 0640) or were they (vdsm:kvm 0644 <- notice world read)
Sorry for the late reply.
Yes sure.
My oVirt engine is also the same system that is the NFS server,
because I'm using FC storage my only NFS server requirement at the
moment is for the ISO domain.
My /etc/group had a group name of "vdsm" assigned to gid "36" and all
I did was change the group name to "kvm".
The node/s(Centos 6.3 64bit dreyou repo) showed the nfs mount as user
"vdsm" but group "nobody"
Once I'd changed the group name I ran the following "chown -R 36:36
/iso-domain" despite an "ls -al" showing the correct owner(vdsm:kvm).
I then put my ISO domain into maintenance and checked that the nfs
share unmounted from the node/s and then re-activated it again, and
then the correct nfs group(kvm) was showing from the node/s.
Note that on this new ISO domain, I haven't modified the permissions
at all, only a "chown -R 36:36" was run once, these are my
permissions at the moment...
"drwxr-xr-x. 3 vdsm kvm 4096 Oct 16 17:37 iso-domain"
if I go to the images folder these are the current permissions on the images...
-rw-r-----. 1 vdsm kvm 127926272 Oct 16 17:40
clonezilla-live-20120525-precise.iso
I hope this helps, please shout if you need any further info.
Regards.
Neil Wilson.
9:40 a.m.
On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
Hi Keith,
On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts(a)redhat.com> wrote:
> Neil,
>
> I suspect that you are having the same issue described in [1].
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
I unfortunately don't have access to view this bug...
"You are not authorized to access bug #858880."
Is there any progress on repairing it, or do you know if there is a
work round in the meantime?
You can try going into the nfs share manually and
chown 36:36 *
i.e., if your iso domain is at /export/iso:
chown 36:36 /export/iso/<uuid>/images/<uuid>/*
Note that the uuid is different in both cases above, and for each
domain.
Not sure if this will help or not, but it's worth a shot.
Mike
Thanks!
Regards.
Neil Wilson.
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
9:47 a.m.
2012/10/16 Mike Burns <mburns(a)redhat.com>
On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
> Hi Keith,
>
> On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts(a)redhat.com>
wrote:
> > Neil,
> >
> > I suspect that you are having the same issue described in [1].
> >
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>
> I unfortunately don't have access to view this bug...
>
> "You are not authorized to access bug #858880."
>
> Is there any progress on repairing it, or do you know if there is a
> work round in the meantime?
You can try going into the nfs share manually and
chown 36:36 *
i.e., if your iso domain is at /export/iso:
chown 36:36 /export/iso/<uuid>/images/<uuid>/*
Note that the uuid is different in both cases above, and for each
domain.
Not sure if this will help or not, but it's worth a shot.
Mike
>
> Thanks!
>
> Regards.
>
> Neil Wilson.
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
Do you have a group kvm with gid = 36?
Alex
9:55 a.m.
On Tue, 2012-10-16 at 15:47 +0100, Alexandre Santos wrote:
2012/10/16 Mike Burns <mburns(a)redhat.com>
On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
> Hi Keith,
>
> On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson
<kroberts(a)redhat.com> wrote:
> > Neil,
> >
> > I suspect that you are having the same issue described in
[1].
> >
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>
> I unfortunately don't have access to view this bug...
>
> "You are not authorized to access bug #858880."
>
> Is there any progress on repairing it, or do you know if
there is a
> work round in the meantime?
You can try going into the nfs share manually and
chown 36:36 *
i.e., if your iso domain is at /export/iso:
chown 36:36 /export/iso/<uuid>/images/<uuid>/*
Note that the uuid is different in both cases above, and for
each
domain.
Not sure if this will help or not, but it's worth a shot.
Mike
>
> Thanks!
>
> Regards.
>
> Neil Wilson.
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
Do you have a group kvm with gid = 36?
36:36 is vdsm:kvm
Mike
Alex
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
9:58 a.m.
On 10/16/2012 10:55 AM, Mike Burns wrote:
> The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
> >Do you have a group kvm with gid = 36?
36:36 is vdsm:kvm
Mike
It will only show 'kvm' if the group ID in /etc/groups ==
'kvm' or if
pam.d reports 36 == kvm from an LDAP bakend or something. In any case,
I doubt it matters... but it might if the code is looking up a user by
name/group.
10:10 a.m.
On Tue, Oct 16, 2012 at 4:47 PM, Alexandre Santos <santosam72(a)gmail.com> wrote:
2012/10/16 Mike Burns <mburns(a)redhat.com>
>
> On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
> > Hi Keith,
> >
> > On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <kroberts(a)redhat.com>
> > wrote:
> > > Neil,
> > >
> > > I suspect that you are having the same issue described in [1].
> > >
> > >
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
> >
> > I unfortunately don't have access to view this bug...
> >
> > "You are not authorized to access bug #858880."
> >
> > Is there any progress on repairing it, or do you know if there is a
> > work round in the meantime?
>
> You can try going into the nfs share manually and
>
> chown 36:36 *
>
> i.e., if your iso domain is at /export/iso:
>
> chown 36:36 /export/iso/<uuid>/images/<uuid>/*
>
> Note that the uuid is different in both cases above, and for each
> domain.
>
> Not sure if this will help or not, but it's worth a shot.
>
> Mike
>
> >
> > Thanks!
> >
> > Regards.
> >
> > Neil Wilson.
> > _______________________________________________
> > Users mailing list
> > Users(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
Do you have a group kvm with gid = 36?
Alex
Hi Alex,
I only have a group called vdsm with gid 36...no group kvm.
grep 36 /etc/group
vdsm:x:36:
Same as my user..
grep 36 /etc/passwd
vdsm:x:36:36::/home/vdsm:/bin/false
Thanks
10:53 a.m.
On Tue, Oct 16, 2012 at 5:10 PM, Neil <nwilson123(a)gmail.com> wrote:
On Tue, Oct 16, 2012 at 4:47 PM, Alexandre Santos
<santosam72(a)gmail.com> wrote:
>
>
> 2012/10/16 Mike Burns <mburns(a)redhat.com>
>>
>> On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
>> > Hi Keith,
>> >
>> > On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson
<kroberts(a)redhat.com>
>> > wrote:
>> > > Neil,
>> > >
>> > > I suspect that you are having the same issue described in [1].
>> > >
>> > >
>> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>> >
>> > I unfortunately don't have access to view this bug...
>> >
>> > "You are not authorized to access bug #858880."
>> >
>> > Is there any progress on repairing it, or do you know if there is a
>> > work round in the meantime?
>>
>> You can try going into the nfs share manually and
>>
>> chown 36:36 *
>>
>> i.e., if your iso domain is at /export/iso:
>>
>> chown 36:36 /export/iso/<uuid>/images/<uuid>/*
>>
>> Note that the uuid is different in both cases above, and for each
>> domain.
>>
>> Not sure if this will help or not, but it's worth a shot.
>>
>> Mike
>>
>> >
>> > Thanks!
>> >
>> > Regards.
>> >
>> > Neil Wilson.
>> > _______________________________________________
>> > Users mailing list
>> > Users(a)ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>
>
> The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
> Do you have a group kvm with gid = 36?
>
> Alex
Hi Alex,
I only have a group called vdsm with gid 36...no group kvm.
grep 36 /etc/group
vdsm:x:36:
Same as my user..
grep 36 /etc/passwd
vdsm:x:36:36::/home/vdsm:/bin/false
Thanks
After messing around with permissions 640 644, 777 and changing
groups, every time I clicked on the "images" tab my whole storage
would go offline, so I've now destroyed by old ISO domain and
re-created it with these exact steps.
Just tried destroying my ISO domain and added a new one, but still the
images don't show.
mv iso-domain iso-domain-old
mkdir iso-domain
chown -R 36:36 iso-domain
ls -al
drwxr-xr-x. 3 vdsm vdsm 4096 Oct 16 17:37 iso-domain
In ovirt I went to storages --> NEW domain, and added it as NFS ISO,
it added, I then activated it and then uploaded a small ISO image, but
still the image doesn't show.
On my host I ran...
vdsClient -s 0 getIsoList `vdsClient -s 0 getConnectedStoragePoolsList`
------ ISO list with proper permissions only -------
I see that on my host the uid and gid of 36 are vdsm:kvm not sure if
this is somehow related?
This is what I see in my server.log when I click on images now...
(note that my storage stays online now though since re-creating)
2012-10-16 17:51:43,596 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
(ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
compatabilityVersion = null), log id: 5ee36683
2012-10-16 17:51:43,599 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
5ee36683
2012-10-16 17:51:43,602 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
(ajp--0.0.0.0-8009-4) START, GetIsoListVDSCommand(storagePoolId =
2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
compatabilityVersion = null), log id: e413685
2012-10-16 17:51:43,621 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
(ajp--0.0.0.0-8009-4) START, HsmGetIsoListVDSCommand(vdsId =
322cbee8-16e6-11e2-9d38-6388c61dd004,
storagePoolId=2e10a712-16e5-11e2-8e00-fb7c1ec24d65), log id: 19d3e418
2012-10-16 17:51:43,678 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, HsmGetIsoListVDSCommand, return: [], log
id: 19d3e418
2012-10-16 17:51:43,703 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, GetIsoListVDSCommand, return: [], log
id: e413685
2012-10-16 17:51:43,802 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
(ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
compatabilityVersion = null), log id: 2f63dd4f
2012-10-16 17:51:43,807 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
2f63dd4f
2012-10-16 17:51:43,814 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
(ajp--0.0.0.0-8009-4) START, GetFloppyListVDSCommand(storagePoolId =
2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
compatabilityVersion = null), log id: 69594af5
2012-10-16 17:51:43,839 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, GetFloppyListVDSCommand, return: [], log
id: 69594af5
Not sure what to try next though.
Thanks for all your assistance so far.
Regards.
Neil Wilson.
10:57 a.m.
2012/10/16 Neil <nwilson123(a)gmail.com>
On Tue, Oct 16, 2012 at 5:10 PM, Neil <nwilson123(a)gmail.com>
wrote:
> On Tue, Oct 16, 2012 at 4:47 PM, Alexandre Santos <santosam72(a)gmail.com>
wrote:
>>
>>
>> 2012/10/16 Mike Burns <mburns(a)redhat.com>
>>>
>>> On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
>>> > Hi Keith,
>>> >
>>> > On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson <
kroberts(a)redhat.com>
>>> > wrote:
>>> > > Neil,
>>> > >
>>> > > I suspect that you are having the same issue described in [1].
>>> > >
>>> > >
>>> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>>> >
>>> > I unfortunately don't have access to view this bug...
>>> >
>>> > "You are not authorized to access bug #858880."
>>> >
>>> > Is there any progress on repairing it, or do you know if there is a
>>> > work round in the meantime?
>>>
>>> You can try going into the nfs share manually and
>>>
>>> chown 36:36 *
>>>
>>> i.e., if your iso domain is at /export/iso:
>>>
>>> chown 36:36 /export/iso/<uuid>/images/<uuid>/*
>>>
>>> Note that the uuid is different in both cases above, and for each
>>> domain.
>>>
>>> Not sure if this will help or not, but it's worth a shot.
>>>
>>> Mike
>>>
>>> >
>>> > Thanks!
>>> >
>>> > Regards.
>>> >
>>> > Neil Wilson.
>>> > _______________________________________________
>>> > Users mailing list
>>> > Users(a)ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>> The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
>> Do you have a group kvm with gid = 36?
>>
>> Alex
>
> Hi Alex,
>
> I only have a group called vdsm with gid 36...no group kvm.
>
> grep 36 /etc/group
> vdsm:x:36:
>
> Same as my user..
>
> grep 36 /etc/passwd
> vdsm:x:36:36::/home/vdsm:/bin/false
>
> Thanks
After messing around with permissions 640 644, 777 and changing
groups, every time I clicked on the "images" tab my whole storage
would go offline, so I've now destroyed by old ISO domain and
re-created it with these exact steps.
Just tried destroying my ISO domain and added a new one, but still the
images don't show.
mv iso-domain iso-domain-old
mkdir iso-domain
chown -R 36:36 iso-domain
ls -al
drwxr-xr-x. 3 vdsm vdsm 4096 Oct 16 17:37 iso-domain
In ovirt I went to storages --> NEW domain, and added it as NFS ISO,
it added, I then activated it and then uploaded a small ISO image, but
still the image doesn't show.
On my host I ran...
vdsClient -s 0 getIsoList `vdsClient -s 0 getConnectedStoragePoolsList`
------ ISO list with proper permissions only -------
I see that on my host the uid and gid of 36 are vdsm:kvm not sure if
this is somehow related?
This is what I see in my server.log when I click on images now...
(note that my storage stays online now though since re-creating)
2012-10-16 17:51:43,596 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
(ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
compatabilityVersion = null), log id: 5ee36683
2012-10-16 17:51:43,599 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
5ee36683
2012-10-16 17:51:43,602 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
(ajp--0.0.0.0-8009-4) START, GetIsoListVDSCommand(storagePoolId =
2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
compatabilityVersion = null), log id: e413685
2012-10-16 17:51:43,621 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
(ajp--0.0.0.0-8009-4) START, HsmGetIsoListVDSCommand(vdsId =
322cbee8-16e6-11e2-9d38-6388c61dd004,
storagePoolId=2e10a712-16e5-11e2-8e00-fb7c1ec24d65), log id: 19d3e418
2012-10-16 17:51:43,678 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, HsmGetIsoListVDSCommand, return: [], log
id: 19d3e418
2012-10-16 17:51:43,703 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, GetIsoListVDSCommand, return: [], log
id: e413685
2012-10-16 17:51:43,802 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
(ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
compatabilityVersion = null), log id: 2f63dd4f
2012-10-16 17:51:43,807 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
2f63dd4f
2012-10-16 17:51:43,814 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
(ajp--0.0.0.0-8009-4) START, GetFloppyListVDSCommand(storagePoolId =
2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
compatabilityVersion = null), log id: 69594af5
2012-10-16 17:51:43,839 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
(ajp--0.0.0.0-8009-4) FINISH, GetFloppyListVDSCommand, return: [], log
id: 69594af5
Not sure what to try next though.
Thanks for all your assistance so far.
Regards.
Neil Wilson.
Going to your host console, what do you see on the owner and permitions of
the ISO domain? I had a similar issue with a ubuntu server that exported
the NFS share as nobody.nobody instead of vdsm.kvm on the host. That domain
was activated but I couldn't get to the share with a "permeation denied"
error"
11:16 a.m.
On Tue, Oct 16, 2012 at 5:57 PM, Alexandre Santos <santosam72(a)gmail.com> wrote:
2012/10/16 Neil <nwilson123(a)gmail.com>
>
> On Tue, Oct 16, 2012 at 5:10 PM, Neil <nwilson123(a)gmail.com> wrote:
> > On Tue, Oct 16, 2012 at 4:47 PM, Alexandre Santos <santosam72(a)gmail.com>
> > wrote:
> >>
> >>
> >> 2012/10/16 Mike Burns <mburns(a)redhat.com>
> >>>
> >>> On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
> >>> > Hi Keith,
> >>> >
> >>> > On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson
> >>> > <kroberts(a)redhat.com>
> >>> > wrote:
> >>> > > Neil,
> >>> > >
> >>> > > I suspect that you are having the same issue described in
[1].
> >>> > >
> >>> > >
> >>> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
> >>> >
> >>> > I unfortunately don't have access to view this bug...
> >>> >
> >>> > "You are not authorized to access bug #858880."
> >>> >
> >>> > Is there any progress on repairing it, or do you know if there is
a
> >>> > work round in the meantime?
> >>>
> >>> You can try going into the nfs share manually and
> >>>
> >>> chown 36:36 *
> >>>
> >>> i.e., if your iso domain is at /export/iso:
> >>>
> >>> chown 36:36 /export/iso/<uuid>/images/<uuid>/*
> >>>
> >>> Note that the uuid is different in both cases above, and for each
> >>> domain.
> >>>
> >>> Not sure if this will help or not, but it's worth a shot.
> >>>
> >>> Mike
> >>>
> >>> >
> >>> > Thanks!
> >>> >
> >>> > Regards.
> >>> >
> >>> > Neil Wilson.
> >>> > _______________________________________________
> >>> > Users mailing list
> >>> > Users(a)ovirt.org
> >>> > http://lists.ovirt.org/mailman/listinfo/users
> >>>
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users(a)ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/users
> >>
> >>
> >> The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
> >> Do you have a group kvm with gid = 36?
> >>
> >> Alex
> >
> > Hi Alex,
> >
> > I only have a group called vdsm with gid 36...no group kvm.
> >
> > grep 36 /etc/group
> > vdsm:x:36:
> >
> > Same as my user..
> >
> > grep 36 /etc/passwd
> > vdsm:x:36:36::/home/vdsm:/bin/false
> >
> > Thanks
>
> After messing around with permissions 640 644, 777 and changing
> groups, every time I clicked on the "images" tab my whole storage
> would go offline, so I've now destroyed by old ISO domain and
> re-created it with these exact steps.
>
> Just tried destroying my ISO domain and added a new one, but still the
> images don't show.
>
> mv iso-domain iso-domain-old
> mkdir iso-domain
> chown -R 36:36 iso-domain
> ls -al
> drwxr-xr-x. 3 vdsm vdsm 4096 Oct 16 17:37 iso-domain
>
> In ovirt I went to storages --> NEW domain, and added it as NFS ISO,
> it added, I then activated it and then uploaded a small ISO image, but
> still the image doesn't show.
>
> On my host I ran...
> vdsClient -s 0 getIsoList `vdsClient -s 0 getConnectedStoragePoolsList`
> ------ ISO list with proper permissions only -------
>
> I see that on my host the uid and gid of 36 are vdsm:kvm not sure if
> this is somehow related?
>
> This is what I see in my server.log when I click on images now...
> (note that my storage stays online now though since re-creating)
>
> 2012-10-16 17:51:43,596 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
> compatabilityVersion = null), log id: 5ee36683
> 2012-10-16 17:51:43,599 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
> 5ee36683
> 2012-10-16 17:51:43,602 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
> (ajp--0.0.0.0-8009-4) START, GetIsoListVDSCommand(storagePoolId =
> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
> compatabilityVersion = null), log id: e413685
> 2012-10-16 17:51:43,621 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
> (ajp--0.0.0.0-8009-4) START, HsmGetIsoListVDSCommand(vdsId =
> 322cbee8-16e6-11e2-9d38-6388c61dd004,
> storagePoolId=2e10a712-16e5-11e2-8e00-fb7c1ec24d65), log id: 19d3e418
> 2012-10-16 17:51:43,678 INFO
> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
> (ajp--0.0.0.0-8009-4) FINISH, HsmGetIsoListVDSCommand, return: [], log
> id: 19d3e418
> 2012-10-16 17:51:43,703 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
> (ajp--0.0.0.0-8009-4) FINISH, GetIsoListVDSCommand, return: [], log
> id: e413685
> 2012-10-16 17:51:43,802 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
> compatabilityVersion = null), log id: 2f63dd4f
> 2012-10-16 17:51:43,807 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
> 2f63dd4f
> 2012-10-16 17:51:43,814 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
> (ajp--0.0.0.0-8009-4) START, GetFloppyListVDSCommand(storagePoolId =
> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
> compatabilityVersion = null), log id: 69594af5
> 2012-10-16 17:51:43,839 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
> (ajp--0.0.0.0-8009-4) FINISH, GetFloppyListVDSCommand, return: [], log
> id: 69594af5
>
> Not sure what to try next though.
>
> Thanks for all your assistance so far.
>
> Regards.
>
> Neil Wilson.
Going to your host console, what do you see on the owner and permitions of
the ISO domain? I had a similar issue with a ubuntu server that exported the
NFS share as nobody.nobody instead of vdsm.kvm on the host. That domain was
activated but I couldn't get to the share with a "permeation denied"
error"
Strangely enough, I see a similar issue...
drwxr-xr-x. 3 vdsm nobody 4096 Oct 16 17:37 10.251.193.5:_iso-domain
Any ideas how to correct it?
11:35 a.m.
Thanks to all for your assistance, I've managed to solve it.
Solved!
On Tue, Oct 16, 2012 at 6:16 PM, Neil <nwilson123(a)gmail.com> wrote:
On Tue, Oct 16, 2012 at 5:57 PM, Alexandre Santos
<santosam72(a)gmail.com> wrote:
> 2012/10/16 Neil <nwilson123(a)gmail.com>
>>
>> On Tue, Oct 16, 2012 at 5:10 PM, Neil <nwilson123(a)gmail.com> wrote:
>> > On Tue, Oct 16, 2012 at 4:47 PM, Alexandre Santos
<santosam72(a)gmail.com>
>> > wrote:
>> >>
>> >>
>> >> 2012/10/16 Mike Burns <mburns(a)redhat.com>
>> >>>
>> >>> On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
>> >>> > Hi Keith,
>> >>> >
>> >>> > On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson
>> >>> > <kroberts(a)redhat.com>
>> >>> > wrote:
>> >>> > > Neil,
>> >>> > >
>> >>> > > I suspect that you are having the same issue described in
[1].
>> >>> > >
>> >>> > >
>> >>> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>> >>> >
>> >>> > I unfortunately don't have access to view this bug...
>> >>> >
>> >>> > "You are not authorized to access bug #858880."
>> >>> >
>> >>> > Is there any progress on repairing it, or do you know if there
is a
>> >>> > work round in the meantime?
>> >>>
>> >>> You can try going into the nfs share manually and
>> >>>
>> >>> chown 36:36 *
>> >>>
>> >>> i.e., if your iso domain is at /export/iso:
>> >>>
>> >>> chown 36:36 /export/iso/<uuid>/images/<uuid>/*
>> >>>
>> >>> Note that the uuid is different in both cases above, and for each
>> >>> domain.
>> >>>
>> >>> Not sure if this will help or not, but it's worth a shot.
>> >>>
>> >>> Mike
>> >>>
>> >>> >
>> >>> > Thanks!
>> >>> >
>> >>> > Regards.
>> >>> >
>> >>> > Neil Wilson.
>> >>> > _______________________________________________
>> >>> > Users mailing list
>> >>> > Users(a)ovirt.org
>> >>> > http://lists.ovirt.org/mailman/listinfo/users
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Users mailing list
>> >>> Users(a)ovirt.org
>> >>> http://lists.ovirt.org/mailman/listinfo/users
>> >>
>> >>
>> >> The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
>> >> Do you have a group kvm with gid = 36?
>> >>
>> >> Alex
>> >
>> > Hi Alex,
>> >
>> > I only have a group called vdsm with gid 36...no group kvm.
>> >
>> > grep 36 /etc/group
>> > vdsm:x:36:
>> >
>> > Same as my user..
>> >
>> > grep 36 /etc/passwd
>> > vdsm:x:36:36::/home/vdsm:/bin/false
>> >
>> > Thanks
>>
>> After messing around with permissions 640 644, 777 and changing
>> groups, every time I clicked on the "images" tab my whole storage
>> would go offline, so I've now destroyed by old ISO domain and
>> re-created it with these exact steps.
>>
>> Just tried destroying my ISO domain and added a new one, but still the
>> images don't show.
>>
>> mv iso-domain iso-domain-old
>> mkdir iso-domain
>> chown -R 36:36 iso-domain
>> ls -al
>> drwxr-xr-x. 3 vdsm vdsm 4096 Oct 16 17:37 iso-domain
>>
>> In ovirt I went to storages --> NEW domain, and added it as NFS ISO,
>> it added, I then activated it and then uploaded a small ISO image, but
>> still the image doesn't show.
>>
>> On my host I ran...
>> vdsClient -s 0 getIsoList `vdsClient -s 0 getConnectedStoragePoolsList`
>> ------ ISO list with proper permissions only -------
>>
>> I see that on my host the uid and gid of 36 are vdsm:kvm not sure if
>> this is somehow related?
>>
>> This is what I see in my server.log when I click on images now...
>> (note that my storage stays online now though since re-creating)
>>
>> 2012-10-16 17:51:43,596 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>> compatabilityVersion = null), log id: 5ee36683
>> 2012-10-16 17:51:43,599 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
>> 5ee36683
>> 2012-10-16 17:51:43,602 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, GetIsoListVDSCommand(storagePoolId =
>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>> compatabilityVersion = null), log id: e413685
>> 2012-10-16 17:51:43,621 INFO
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, HsmGetIsoListVDSCommand(vdsId =
>> 322cbee8-16e6-11e2-9d38-6388c61dd004,
>> storagePoolId=2e10a712-16e5-11e2-8e00-fb7c1ec24d65), log id: 19d3e418
>> 2012-10-16 17:51:43,678 INFO
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, HsmGetIsoListVDSCommand, return: [], log
>> id: 19d3e418
>> 2012-10-16 17:51:43,703 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, GetIsoListVDSCommand, return: [], log
>> id: e413685
>> 2012-10-16 17:51:43,802 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>> compatabilityVersion = null), log id: 2f63dd4f
>> 2012-10-16 17:51:43,807 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
>> 2f63dd4f
>> 2012-10-16 17:51:43,814 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, GetFloppyListVDSCommand(storagePoolId =
>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>> compatabilityVersion = null), log id: 69594af5
>> 2012-10-16 17:51:43,839 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, GetFloppyListVDSCommand, return: [], log
>> id: 69594af5
>>
>> Not sure what to try next though.
>>
>> Thanks for all your assistance so far.
>>
>> Regards.
>>
>> Neil Wilson.
>
> Going to your host console, what do you see on the owner and permitions of
> the ISO domain? I had a similar issue with a ubuntu server that exported the
> NFS share as nobody.nobody instead of vdsm.kvm on the host. That domain was
> activated but I couldn't get to the share with a "permeation denied"
error"
Strangely enough, I see a similar issue...
drwxr-xr-x. 3 vdsm nobody 4096 Oct 16 17:37 10.251.193.5:_iso-domain
Any ideas how to correct it?
After renaming my gid 36 on my engine to kvm instead of vdsm, then
running a "chown -R 36:36 /iso-domain" on the folder, then setting the
ISO domain into maintenance and then activating it again, it then
mounted with the correct group ownership(kvm instead of nobody as seen
from the host) and I can now see my images!
I'm not sure where this vdsm group(gid 36) came from on my engine? Any
ideas, has this ever changed through different versions of
ovirt-engine?
Thank you very much for all of your assistance, it is greatly appreciated!
Regards.
Neil Wilson.
7:15 p.m.
On 10/16/2012 06:35 PM, Neil wrote:
Thanks to all for your assistance, I've managed to solve it.
Solved!
On Tue, Oct 16, 2012 at 6:16 PM, Neil <nwilson123(a)gmail.com> wrote:
> On Tue, Oct 16, 2012 at 5:57 PM, Alexandre Santos <santosam72(a)gmail.com>
wrote:
>> 2012/10/16 Neil <nwilson123(a)gmail.com>
>>>
>>> On Tue, Oct 16, 2012 at 5:10 PM, Neil <nwilson123(a)gmail.com> wrote:
>>>> On Tue, Oct 16, 2012 at 4:47 PM, Alexandre Santos
<santosam72(a)gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> 2012/10/16 Mike Burns <mburns(a)redhat.com>
>>>>>>
>>>>>> On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
>>>>>>> Hi Keith,
>>>>>>>
>>>>>>> On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson
>>>>>>> <kroberts(a)redhat.com>
>>>>>>> wrote:
>>>>>>>> Neil,
>>>>>>>>
>>>>>>>> I suspect that you are having the same issue described in
[1].
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>>>>>>>
>>>>>>> I unfortunately don't have access to view this bug...
>>>>>>>
>>>>>>> "You are not authorized to access bug #858880."
>>>>>>>
>>>>>>> Is there any progress on repairing it, or do you know if
there is a
>>>>>>> work round in the meantime?
>>>>>>
>>>>>> You can try going into the nfs share manually and
>>>>>>
>>>>>> chown 36:36 *
>>>>>>
>>>>>> i.e., if your iso domain is at /export/iso:
>>>>>>
>>>>>> chown 36:36 /export/iso/<uuid>/images/<uuid>/*
>>>>>>
>>>>>> Note that the uuid is different in both cases above, and for
each
>>>>>> domain.
>>>>>>
>>>>>> Not sure if this will help or not, but it's worth a shot.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Regards.
>>>>>>>
>>>>>>> Neil Wilson.
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>> The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
>>>>> Do you have a group kvm with gid = 36?
>>>>>
>>>>> Alex
>>>>
>>>> Hi Alex,
>>>>
>>>> I only have a group called vdsm with gid 36...no group kvm.
>>>>
>>>> grep 36 /etc/group
>>>> vdsm:x:36:
>>>>
>>>> Same as my user..
>>>>
>>>> grep 36 /etc/passwd
>>>> vdsm:x:36:36::/home/vdsm:/bin/false
>>>>
>>>> Thanks
>>>
>>> After messing around with permissions 640 644, 777 and changing
>>> groups, every time I clicked on the "images" tab my whole storage
>>> would go offline, so I've now destroyed by old ISO domain and
>>> re-created it with these exact steps.
>>>
>>> Just tried destroying my ISO domain and added a new one, but still the
>>> images don't show.
>>>
>>> mv iso-domain iso-domain-old
>>> mkdir iso-domain
>>> chown -R 36:36 iso-domain
>>> ls -al
>>> drwxr-xr-x. 3 vdsm vdsm 4096 Oct 16 17:37 iso-domain
>>>
>>> In ovirt I went to storages --> NEW domain, and added it as NFS ISO,
>>> it added, I then activated it and then uploaded a small ISO image, but
>>> still the image doesn't show.
>>>
>>> On my host I ran...
>>> vdsClient -s 0 getIsoList `vdsClient -s 0 getConnectedStoragePoolsList`
>>> ------ ISO list with proper permissions only -------
>>>
>>> I see that on my host the uid and gid of 36 are vdsm:kvm not sure if
>>> this is somehow related?
>>>
>>> This is what I see in my server.log when I click on images now...
>>> (note that my storage stays online now though since re-creating)
>>>
>>> 2012-10-16 17:51:43,596 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
>>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>>> compatabilityVersion = null), log id: 5ee36683
>>> 2012-10-16 17:51:43,599 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
>>> 5ee36683
>>> 2012-10-16 17:51:43,602 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, GetIsoListVDSCommand(storagePoolId =
>>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>>> compatabilityVersion = null), log id: e413685
>>> 2012-10-16 17:51:43,621 INFO
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, HsmGetIsoListVDSCommand(vdsId =
>>> 322cbee8-16e6-11e2-9d38-6388c61dd004,
>>> storagePoolId=2e10a712-16e5-11e2-8e00-fb7c1ec24d65), log id: 19d3e418
>>> 2012-10-16 17:51:43,678 INFO
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, HsmGetIsoListVDSCommand, return: [], log
>>> id: 19d3e418
>>> 2012-10-16 17:51:43,703 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, GetIsoListVDSCommand, return: [], log
>>> id: e413685
>>> 2012-10-16 17:51:43,802 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
>>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>>> compatabilityVersion = null), log id: 2f63dd4f
>>> 2012-10-16 17:51:43,807 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
>>> 2f63dd4f
>>> 2012-10-16 17:51:43,814 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, GetFloppyListVDSCommand(storagePoolId =
>>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>>> compatabilityVersion = null), log id: 69594af5
>>> 2012-10-16 17:51:43,839 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, GetFloppyListVDSCommand, return: [], log
>>> id: 69594af5
>>>
>>> Not sure what to try next though.
>>>
>>> Thanks for all your assistance so far.
>>>
>>> Regards.
>>>
>>> Neil Wilson.
>>
>> Going to your host console, what do you see on the owner and permitions of
>> the ISO domain? I had a similar issue with a ubuntu server that exported the
>> NFS share as nobody.nobody instead of vdsm.kvm on the host. That domain was
>> activated but I couldn't get to the share with a "permeation
denied" error"
>
> Strangely enough, I see a similar issue...
>
> drwxr-xr-x. 3 vdsm nobody 4096 Oct 16 17:37 10.251.193.5:_iso-domain
>
> Any ideas how to correct it?
After renaming my gid 36 on my engine to kvm instead of vdsm, then
running a "chown -R 36:36 /iso-domain" on the folder, then setting the
ISO domain into maintenance and then activating it again, it then
mounted with the correct group ownership(kvm instead of nobody as seen
from the host) and I can now see my images!
I'm not sure where this vdsm group(gid 36) came from on my engine? Any
ideas, has this ever changed through different versions of
ovirt-engine?
Thank you very much for all of your assistance, it is greatly appreciated!
please wikify for others at
http://www.ovirt.org/wiki/Troubleshooting_NFS_Storage_Issues
thanks,
Itamar
1:03 a.m.
I used to have the similar issue that the owner or group of directory
became nobody. But I don't have the enviroment to reproduce it now.
2012-10-17 0:16, Neil:
On Tue, Oct 16, 2012 at 5:57 PM, Alexandre Santos
<santosam72(a)gmail.com> wrote:
> 2012/10/16 Neil <nwilson123(a)gmail.com>
>> On Tue, Oct 16, 2012 at 5:10 PM, Neil <nwilson123(a)gmail.com> wrote:
>>> On Tue, Oct 16, 2012 at 4:47 PM, Alexandre Santos
<santosam72(a)gmail.com>
>>> wrote:
>>>>
>>>> 2012/10/16 Mike Burns <mburns(a)redhat.com>
>>>>> On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
>>>>>> Hi Keith,
>>>>>>
>>>>>> On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson
>>>>>> <kroberts(a)redhat.com>
>>>>>> wrote:
>>>>>>> Neil,
>>>>>>>
>>>>>>> I suspect that you are having the same issue described in
[1].
>>>>>>>
>>>>>>>
>>>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>>>>>> I unfortunately don't have access to view this bug...
>>>>>>
>>>>>> "You are not authorized to access bug #858880."
>>>>>>
>>>>>> Is there any progress on repairing it, or do you know if there is
a
>>>>>> work round in the meantime?
>>>>> You can try going into the nfs share manually and
>>>>>
>>>>> chown 36:36 *
>>>>>
>>>>> i.e., if your iso domain is at /export/iso:
>>>>>
>>>>> chown 36:36 /export/iso/<uuid>/images/<uuid>/*
>>>>>
>>>>> Note that the uuid is different in both cases above, and for each
>>>>> domain.
>>>>>
>>>>> Not sure if this will help or not, but it's worth a shot.
>>>>>
>>>>> Mike
>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Regards.
>>>>>>
>>>>>> Neil Wilson.
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>> The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
>>>> Do you have a group kvm with gid = 36?
>>>>
>>>> Alex
>>> Hi Alex,
>>>
>>> I only have a group called vdsm with gid 36...no group kvm.
>>>
>>> grep 36 /etc/group
>>> vdsm:x:36:
>>>
>>> Same as my user..
>>>
>>> grep 36 /etc/passwd
>>> vdsm:x:36:36::/home/vdsm:/bin/false
>>>
>>> Thanks
>> After messing around with permissions 640 644, 777 and changing
>> groups, every time I clicked on the "images" tab my whole storage
>> would go offline, so I've now destroyed by old ISO domain and
>> re-created it with these exact steps.
>>
>> Just tried destroying my ISO domain and added a new one, but still the
>> images don't show.
>>
>> mv iso-domain iso-domain-old
>> mkdir iso-domain
>> chown -R 36:36 iso-domain
>> ls -al
>> drwxr-xr-x. 3 vdsm vdsm 4096 Oct 16 17:37 iso-domain
>>
>> In ovirt I went to storages --> NEW domain, and added it as NFS ISO,
>> it added, I then activated it and then uploaded a small ISO image, but
>> still the image doesn't show.
>>
>> On my host I ran...
>> vdsClient -s 0 getIsoList `vdsClient -s 0 getConnectedStoragePoolsList`
>> ------ ISO list with proper permissions only -------
>>
>> I see that on my host the uid and gid of 36 are vdsm:kvm not sure if
>> this is somehow related?
>>
>> This is what I see in my server.log when I click on images now...
>> (note that my storage stays online now though since re-creating)
>>
>> 2012-10-16 17:51:43,596 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>> compatabilityVersion = null), log id: 5ee36683
>> 2012-10-16 17:51:43,599 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
>> 5ee36683
>> 2012-10-16 17:51:43,602 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, GetIsoListVDSCommand(storagePoolId =
>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>> compatabilityVersion = null), log id: e413685
>> 2012-10-16 17:51:43,621 INFO
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, HsmGetIsoListVDSCommand(vdsId =
>> 322cbee8-16e6-11e2-9d38-6388c61dd004,
>> storagePoolId=2e10a712-16e5-11e2-8e00-fb7c1ec24d65), log id: 19d3e418
>> 2012-10-16 17:51:43,678 INFO
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, HsmGetIsoListVDSCommand, return: [], log
>> id: 19d3e418
>> 2012-10-16 17:51:43,703 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, GetIsoListVDSCommand, return: [], log
>> id: e413685
>> 2012-10-16 17:51:43,802 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>> compatabilityVersion = null), log id: 2f63dd4f
>> 2012-10-16 17:51:43,807 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
>> 2f63dd4f
>> 2012-10-16 17:51:43,814 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
>> (ajp--0.0.0.0-8009-4) START, GetFloppyListVDSCommand(storagePoolId =
>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>> compatabilityVersion = null), log id: 69594af5
>> 2012-10-16 17:51:43,839 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
>> (ajp--0.0.0.0-8009-4) FINISH, GetFloppyListVDSCommand, return: [], log
>> id: 69594af5
>>
>> Not sure what to try next though.
>>
>> Thanks for all your assistance so far.
>>
>> Regards.
>>
>> Neil Wilson.
>
>
> Going to your host console, what do you see on the owner and permitions of
> the ISO domain? I had a similar issue with a ubuntu server that exported the
> NFS share as nobody.nobody instead of vdsm.kvm on the host. That domain was
> activated but I couldn't get to the share with a "permeation denied"
error"
Strangely enough, I see a similar issue...
drwxr-xr-x. 3 vdsm nobody 4096 Oct 16 17:37 10.251.193.5:_iso-domain
Any ideas how to correct it?
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
---
舒明 Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or
shuming(a)linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193,
PRC
8:42 a.m.
On 10/18/2012 02:03 AM, Shu Ming wrote:
I used to have the similar issue that the owner or group of directory
became nobody. But I don't have the enviroment to reproduce it now.
Nobody is
just an NFS built-in. I think this generally occurs when the
UID and GID of the files on the NFS server do not have an analog on the
client.
In other words, if on the server the files are 1001 and the client
doesn't have a 1001 the client will see 'nobody'. There are also all
sorts of NFS server arguments that you can use to force this condition
(I beleive).
Cheers,
Keith
2012-10-17 0:16, Neil:
> On Tue, Oct 16, 2012 at 5:57 PM, Alexandre Santos
> <santosam72(a)gmail.com> wrote:
>> 2012/10/16 Neil <nwilson123(a)gmail.com>
>>> On Tue, Oct 16, 2012 at 5:10 PM, Neil <nwilson123(a)gmail.com> wrote:
>>>> On Tue, Oct 16, 2012 at 4:47 PM, Alexandre Santos
>>>> <santosam72(a)gmail.com>
>>>> wrote:
>>>>>
>>>>> 2012/10/16 Mike Burns <mburns(a)redhat.com>
>>>>>> On Tue, 2012-10-16 at 16:33 +0200, Neil wrote:
>>>>>>> Hi Keith,
>>>>>>>
>>>>>>> On Tue, Oct 16, 2012 at 3:48 PM, Keith Robertson
>>>>>>> <kroberts(a)redhat.com>
>>>>>>> wrote:
>>>>>>>> Neil,
>>>>>>>>
>>>>>>>> I suspect that you are having the same issue described in
[1].
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=858880
>>>>>>> I unfortunately don't have access to view this bug...
>>>>>>>
>>>>>>> "You are not authorized to access bug #858880."
>>>>>>>
>>>>>>> Is there any progress on repairing it, or do you know if
there
>>>>>>> is a
>>>>>>> work round in the meantime?
>>>>>> You can try going into the nfs share manually and
>>>>>>
>>>>>> chown 36:36 *
>>>>>>
>>>>>> i.e., if your iso domain is at /export/iso:
>>>>>>
>>>>>> chown 36:36 /export/iso/<uuid>/images/<uuid>/*
>>>>>>
>>>>>> Note that the uuid is different in both cases above, and for
each
>>>>>> domain.
>>>>>>
>>>>>> Not sure if this will help or not, but it's worth a shot.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Regards.
>>>>>>>
>>>>>>> Neil Wilson.
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>> The owner 36:36 should be vdsm.kvm and not vdsm.vdsm
>>>>> Do you have a group kvm with gid = 36?
>>>>>
>>>>> Alex
>>>> Hi Alex,
>>>>
>>>> I only have a group called vdsm with gid 36...no group kvm.
>>>>
>>>> grep 36 /etc/group
>>>> vdsm:x:36:
>>>>
>>>> Same as my user..
>>>>
>>>> grep 36 /etc/passwd
>>>> vdsm:x:36:36::/home/vdsm:/bin/false
>>>>
>>>> Thanks
>>> After messing around with permissions 640 644, 777 and changing
>>> groups, every time I clicked on the "images" tab my whole storage
>>> would go offline, so I've now destroyed by old ISO domain and
>>> re-created it with these exact steps.
>>>
>>> Just tried destroying my ISO domain and added a new one, but still the
>>> images don't show.
>>>
>>> mv iso-domain iso-domain-old
>>> mkdir iso-domain
>>> chown -R 36:36 iso-domain
>>> ls -al
>>> drwxr-xr-x. 3 vdsm vdsm 4096 Oct 16 17:37 iso-domain
>>>
>>> In ovirt I went to storages --> NEW domain, and added it as NFS ISO,
>>> it added, I then activated it and then uploaded a small ISO image, but
>>> still the image doesn't show.
>>>
>>> On my host I ran...
>>> vdsClient -s 0 getIsoList `vdsClient -s 0
>>> getConnectedStoragePoolsList`
>>> ------ ISO list with proper permissions only -------
>>>
>>> I see that on my host the uid and gid of 36 are vdsm:kvm not sure if
>>> this is somehow related?
>>>
>>> This is what I see in my server.log when I click on images now...
>>> (note that my storage stays online now though since re-creating)
>>>
>>> 2012-10-16 17:51:43,596 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
>>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>>> compatabilityVersion = null), log id: 5ee36683
>>> 2012-10-16 17:51:43,599 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
>>> 5ee36683
>>> 2012-10-16 17:51:43,602 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, GetIsoListVDSCommand(storagePoolId =
>>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>>> compatabilityVersion = null), log id: e413685
>>> 2012-10-16 17:51:43,621 INFO
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, HsmGetIsoListVDSCommand(vdsId =
>>> 322cbee8-16e6-11e2-9d38-6388c61dd004,
>>> storagePoolId=2e10a712-16e5-11e2-8e00-fb7c1ec24d65), log id: 19d3e418
>>> 2012-10-16 17:51:43,678 INFO
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, HsmGetIsoListVDSCommand, return: [], log
>>> id: 19d3e418
>>> 2012-10-16 17:51:43,703 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetIsoListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, GetIsoListVDSCommand, return: [], log
>>> id: e413685
>>> 2012-10-16 17:51:43,802 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, IsValidVDSCommand(storagePoolId =
>>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>>> compatabilityVersion = null), log id: 2f63dd4f
>>> 2012-10-16 17:51:43,807 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.IsValidVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, IsValidVDSCommand, return: true, log id:
>>> 2f63dd4f
>>> 2012-10-16 17:51:43,814 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) START, GetFloppyListVDSCommand(storagePoolId =
>>> 2e10a712-16e5-11e2-8e00-fb7c1ec24d65, ignoreFailoverLimit = false,
>>> compatabilityVersion = null), log id: 69594af5
>>> 2012-10-16 17:51:43,839 INFO
>>> [org.ovirt.engine.core.vdsbroker.irsbroker.GetFloppyListVDSCommand]
>>> (ajp--0.0.0.0-8009-4) FINISH, GetFloppyListVDSCommand, return: [], log
>>> id: 69594af5
>>>
>>> Not sure what to try next though.
>>>
>>> Thanks for all your assistance so far.
>>>
>>> Regards.
>>>
>>> Neil Wilson.
>>
>>
>> Going to your host console, what do you see on the owner and
>> permitions of
>> the ISO domain? I had a similar issue with a ubuntu server that
>> exported the
>> NFS share as nobody.nobody instead of vdsm.kvm on the host. That
>> domain was
>> activated but I couldn't get to the share with a "permeation
denied"
>> error"
> Strangely enough, I see a similar issue...
>
> drwxr-xr-x. 3 vdsm nobody 4096 Oct 16 17:37 10.251.193.5:_iso-domain
>
> Any ideas how to correct it?
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
4216
days inactive
4218
days old
22 comments
8 participants
participants (8)
-
Alexandre Santos -
Haim Ateya -
Itamar Heim -
Juan Hernandez -
Keith Robertson -
Mike Burns -
Neil -
Shu Ming