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

Terry Phelps tgphelps50 at gmail.com
Fri Feb 24 18:35:46 UTC 2012 

Yes, I think so. Note that I'm running the ovirt 3 RPM, and not the
RHEV product, if that matters:

# engine-iso-uploader list
Please provide the REST API password for the admin at internal oVirt
Engine user (CTRL+D to abort):
ISO Storage Domain Name   | Datacenter                | ISO Domain Status
ISODomain                 | Default                   | active


On 2/24/12, Keith Robertson <kroberts at redhat.com> wrote:
> Is your storage domain active?  Just run the "list" command on the iso
> uploader (or look in the UI).
>
> Example:
> [root at rhevm ~]# rhevm-iso-uploader list
> Please provide the REST API password for RHEV-M (CTRL+D to abort):
> ISO Storage Domain Name   | Datacenter                | ISO Domain Status
> iso1                      | Default                   | active
> iso1                      | iSCSI                     | inactive
> iso1                      | NFS                       | active
>
>
> On 02/24/2012 01:04 PM, Terry Phelps wrote:
>> 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?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>

More information about the Users mailing list