[Users] Uploaded ISO file doesn't show up in admin portal

[Terry Phelps]

On 2/24/12, Keith Robertson <kroberts at redhat.com> wrote:
> OK, so VDSM looks fine.  Let's see what the REST API and by extension
> ovirt-engine thinks about it...
>
>  From the host upon which ovirt-engine running do this:
>   wget -q -O - --no-check-certificate --user=admin at internal
> --password='password here'
> https://localhost:8443/api/storagedomains/48a5390f-2f86-485c-8537-b6bc9dd71796/files
>
> Do you see the files?

NOPE:

# cat doit
wget -q -O - --no-check-certificate --user=admin at internal \
   --password=******
https://localhost:8443/api/storagedomains/48a5390f-2f86-485c-8537-b6bc9dd71796/files

[root at oravm3 ~]# sh doit

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<files/>

Maybe this has gotten us closer to the problem.




>
> Cheers,
> Keith
>
> On 02/24/2012 10:28 AM, Terry Phelps wrote:
>> It looks like you were doing this as root, so I did, too. In any case,
>> the result looks good to me:
>>
>> # mount | grep iso
>>
>> oravm3.acbl.net:/isodomain/ on
>> /rhev/data-center/mnt/oravm3.acbl.net:_isodomain type nfs4
>> (rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,soft,nosharecache,proto=tcp,port=0,timeo=600,retrans=6,sec=sys,clientaddr=172.16.2.52,minorversion=0,local_lock=none,addr=192.168.118.10)
>>
>> ]# ls /rhev/data-center/mnt/oravm3.acbl.net:_isodomain
>>
>> 48a5390f-2f86-485c-8537-b6bc9dd71796  vdsmTest
>>
>> [root at oravm2 ~]# vdsClient -s 0 getFileList
>> 48a5390f-2f86-485c-8537-b6bc9dd71796
>>
>> file:  OracleLinux-R6-U2-Server-x86_64-dvd.iso status:  {'status':
>> 469, 'ctime': '1330092866.03', 'size': '3591360512'}
>>
>>
>> NOTE: That "vdsmTest" file you see has appeared there since yesterday,
>> I think. I didn't put it there.
> Have no idea what that is.
>> On 2/24/12, Keith Robertson<kroberts at redhat.com>  wrote:
>>> On 02/24/2012 09:19 AM, Terry Phelps wrote:
>>>> On 2/23/12, Keith Robertson<kroberts at redhat.com>   wrote:
>>>>> On 02/23/2012 02:21 PM, Terry Phelps wrote:
>>>>>> Thanks for the quick reply.
>>>>>>
>>>>>> My one hypervisor already had the ISO domain mounted (without any
>>>>>> explicit action by me):
>>>>> This is to be expected.  VDSM needs the mount. I suggested that command
>>>>> just in case it wasn't mounted for some odd reason.
>>>>>> mount | grep iso
>>>>>>
>>>>>> oravm3.acbl.net:/isodomain/ on
>>>>>> /rhev/data-center/mnt/oravm3.acbl.net:_isodomain type nfs4
>>>>>> (rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,soft,nosharecache,proto=tcp,port=0,timeo=600,retrans=6,sec=sys,clientaddr=172.16.2.52,minorversion=0,local_lock=none,addr=192.168.118.10)
>>>>>>
>>>>>> Using this mount (I didn't do exactly what you said, if that matters),
>>>>> Nope, you're fine.
>>>>>> I did the tests you asked for.
>>>>>> Yes, I can touch a new file.
>>>>>> Yes, I can read the ISO file
>>>>>>
>>>>>> Here is what I saw:
>>>>>>
>>>>> I'm assuming you were "vdsm" when you executed these commands, right?
>>>>>> bash-4.2$ ls
>>>>>> OracleLinux-R6-U2-Server-x86_64-dvd.iso
>>>>>> bash-4.2$ touch me
>>>>>> bash-4.2$ ls
>>>>>> me  OracleLinux-R6-U2-Server-x86_64-dvd.iso
>>>>>> bash-4.2$ strings Orac* |head -2
>>>>>> CD001
>>>>>> LINUX                           OL6.2 x86_64 Disc 1 20111212
>>>>>>
>>>>>>
>>>>>> Funny, though. When I typed "su - vdsm" by mistake, from root, it said
>>>>>> "This account is currently not available." (Is that relevant?) But
>>>>>> what you said to do did work fine.
>>>>> By default vdsm is given a nologin shell for security reasons.  The "-s
>>>>> /bin/bash" overrides that when switching users.
>>>>>> Other ideas/
>>>>> Not at the moment.  I think you've done a fairly good job of
>>>>> demonstrating that VDSM would not have any permission problems reading
>>>>> or writing to the NFS export.
>>>> Just to gather more information, I re-ran engine-iso-uploader to
>>>> upload my ISO. It complained that the ISO was already there, which it
>>>> IS. I used the "--force" option to make him do it again. He did.
>>> Yup, standard behavior.
>>>> It still doesn't show up in the admin portal.
>>>>
>>>> Is there something else I can do to help find the problem?
>>> Well you've demonstrated that the user "vdsm" can r/w the NFS export
>>> from the hypervisor.  This is a common source of problems as things like
>>> selinux and UID/GID mismatches can cause all sorts blockages preventing
>>> VDSM's ability to r/w the NFS export.
>>>
>>> Let's see what VDSM thinks.  From a hypervisor do this...
>>> 1. Type "mount"
>>> 2. Look for your ISO domain in the returned list.
>>> 3. Note the local path to the ISO domain.  It might look something like
>>> this...
>>>    /rhev/data-center/mnt/oravm3.acbl.net:_isodomain
>>> 4. List the directories in it:
>>>     ls /rhev/data-center/mnt/oravm3.acbl.net:_isodomain
>>> 5. Notice the returned UUID directory name:
>>>    [root at node ~]# ls  /rhev/data-center/mnt/oravm3.acbl.net:_isodomain
>>>    92cf90c2-3698-48b5-84fd-d8e4f8684549
>>> 6. Supply that to the vdsClient command as follows:
>>>     vdsClient -s 0  getFileList  92cf90c2-3698-48b5-84fd-d8e4f8684549
>>>
>>> What happens?
>>>
>>>
>>>
>>>
>>>
>
>