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@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@redhat.com> wrote:
Is your storage domain active? Just run the "list" command on the iso uploader (or look in the UI).
Example: [root@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@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@internal --password='password here' https://localhost:8443/api/storagedomains/48a5390f-2f86-485c-8537-b6bc9dd717...
Do you see the files? NOPE:
# cat doit wget -q -O - --no-check-certificate --user=admin@internal \ --password=****** https://localhost:8443/api/storagedomains/48a5390f-2f86-485c-8537-b6bc9dd717...
[root@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@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@redhat.com> wrote:
On 2/23/12, Keith Robertson<kroberts@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
On 02/24/2012 09:19 AM, Terry Phelps wrote: 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?