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@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.
On 2/24/12, Keith Robertson <krobe...@redhat.com> wrote:
> On 02/24/2012 09:19 AM, Terry Phelps wrote:
>> On 2/23/12, Keith Robertson<krobe...@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@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?
>
>
>
>
>
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
