Re: [Users] Uploaded ISO file doesn't show up in admin portal
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. On 2/23/12, Keith Robertson<kroberts@redhat.com> wrote:
Please try this from a hyper-visor:
1. mkdir /mnt/testmount 2. mount<nfs server here>:/isodomain/48a5390f-2f86-485c-8537-b6bc9dd71796/images/11111111-1111-1111-1111-111111111111 /mnt/testmount 3. su -s /bin/bash vdsm<-- Really important. 4. cd /mnt/testmount 5. touch test.txt 6. strings OracleLinux-R6-U2-Server-x86_64-dvd.iso Do steps 5 and 6 work? If they do not then it is a red flag that VDSM cannot r/w your storage domain and this is an error.
On 02/23/2012 02:03 PM, Terry Phelps wrote:
I am experimenting with the recently released oVirt product. I installed ovirt-node 2.2.2 on a server, and the ovirt engine on a new Fedora 16 installation. I attached the ovirt-node to the manager, got it up and ready for use. I created two additional NFS domains, one for data and one for export. Those two and the automatically installed one called "ISODomain" are all three "green" and "active".
On the ovirt manager Fedora box, I used engine-iso-uploader to upload an ISO to "ISODomain". The command was engine-iso-uploader -i ISODomain upload my.iso
This completed okay, and the ISO file has been copied there:
# du -k /isodomain/ 24 /isodomain/48a5390f-2f86-485c-8537-b6bc9dd71796/dom_md 3507196 /isodomain/48a5390f-2f86-485c-8537-b6bc9dd71796/images/11111111-1111-1111-1111-111111111111 3507200 /isodomain/48a5390f-2f86-485c-8537-b6bc9dd71796/images 3507228 /isodomain/48a5390f-2f86-485c-8537-b6bc9dd71796 3507232 /isodomain/
# pwd /isodomain/48a5390f-2f86-485c-8537-b6bc9dd71796/images/11111111-1111-1111-1111-111111111111
[root@oravm3 11111111-1111-1111-1111-111111111111]# ls -l total 3507192 -rw-r-----. 1 vdsm kvm 3591360512 Feb 23 13:24 OracleLinux-R6-U2-Server-x86_64-dvd.iso
The problem is that I can't see the ISO from the ovirt manager. When I open the storage tab, and click on the ISO domain, and then open the images tab, it shows NOTHING. I refreshed it, and even logged out and back in again, but the ISO isn't visible from here.
Shouldn't it be? _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 02/23/2012 02:41 PM, Keith Robertson 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.
nfs-check tool might help here too... it mount, creates (as vdsm:kvsm) and remove file into the nfs mountpoint... http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=contrib/nfs-check.py;h=1b... -- Cheers Douglas
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. It still doesn't show up in the admin portal. Is there something else I can do to help find the problem?
On 02/24/2012 09:19 AM, Terry Phelps 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 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?
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 <kroberts@redhat.com> wrote:
On 02/24/2012 09:19 AM, Terry Phelps 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 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?
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? 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 02/24/2012 09:19 AM, Terry Phelps 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 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?
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 02/24/2012 09:19 AM, Terry Phelps 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 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?
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 02/24/2012 09:19 AM, Terry Phelps 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 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?
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?
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.
You didn't, this file can be removed, yesterday the nfs-check couldn't complete the test (remove the file) as you answered me (below) and it's still there.
# python nfs-check.py oravm3.acbl.net:/isodomain Current hostname: oravm2.acbl.net - IP addr 127.0.0.1 Trying to /bin/mount -t nfs oravm3.acbl.net:/isodomain... Executing NFS tests.. Removing vdsmTest file.. Traceback (most recent call last): File "nfs-check.py", line 268, in<module> os.removedirs(LOCALPATH) File "/usr/lib64/python2.7/os.py", line 170, in removedirs OSError: [Errno 16] Device or resource busy: '/tmp/tmpV9KEh5'
Now I am wondering why... -- Cheers Douglas
Hi Terry, On 02/24/2012 02:51 PM, Douglas Landgraf wrote:
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.
You didn't, this file can be removed, yesterday the nfs-check couldn't complete the test (remove the file) as you answered me (below) and it's still there.
# python nfs-check.py oravm3.acbl.net:/isodomain Current hostname: oravm2.acbl.net - IP addr 127.0.0.1 Trying to /bin/mount -t nfs oravm3.acbl.net:/isodomain... Executing NFS tests.. Removing vdsmTest file.. Traceback (most recent call last): File "nfs-check.py", line 268, in<module> os.removedirs(LOCALPATH) File "/usr/lib64/python2.7/os.py", line 170, in removedirs OSError: [Errno 16] Device or resource busy: '/tmp/tmpV9KEh5'
Just to confirm, during the execution of nfs-check have you manually entry into /tmp/tmpV9KEh5 (from another shell)? If not, this EBUSY error might be like symptom of this weird behaviour... However, let me continue... looking the previous messages of this thread, looks like you have the iso correctly uploaded. Have you tried to restart jboss-as service (oVirt Engine) to see if your iso appears into the GUI? BTW, most of ovirt people are available to chat and help 'on-the-fly' at irc.oftc.net, channel #ovirt , fell free to join us there . -- Cheers Douglas (irc: dougsland)
Terry, Did you try the getsebool and setsebool options I provided, just checking if u happened to miss that mail ?
Terry, Did you try the getsebool and setsebool options I provided, just checking if u happened to miss that mail ?
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users I think the test to r/w files on the NFS export would have exposed that issue. Since Terry was able successfully r/w files in the ISO storage domain as the VDSM user I doubt that this is the root cause. I'd really
On 02/24/2012 12:42 PM, Deepak C Shetty wrote: like to see the output from the wget to the REST API. Cheers, Keith
On 02/24/2012 10:23 PM, Douglas Landgraf wrote:
Hi Terry,
On 02/24/2012 02:51 PM, Douglas Landgraf wrote:
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.
You didn't, this file can be removed, yesterday the nfs-check couldn't complete the test (remove the file) as you answered me (below) and it's still there.
# python nfs-check.py oravm3.acbl.net:/isodomain Current hostname: oravm2.acbl.net - IP addr 127.0.0.1 Trying to /bin/mount -t nfs oravm3.acbl.net:/isodomain... Executing NFS tests.. Removing vdsmTest file.. Traceback (most recent call last): File "nfs-check.py", line 268, in<module> os.removedirs(LOCALPATH) File "/usr/lib64/python2.7/os.py", line 170, in removedirs OSError: [Errno 16] Device or resource busy: '/tmp/tmpV9KEh5'
Just to confirm, during the execution of nfs-check have you manually entry into /tmp/tmpV9KEh5 (from another shell)? If not, this EBUSY error might be like symptom of this weird behaviour...
However, let me continue... looking the previous messages of this thread, looks like you have the iso correctly uploaded. Have you tried to restart jboss-as service (oVirt Engine) to see if your iso appears into the GUI?
BTW, most of ovirt people are available to chat and help 'on-the-fly' at irc.oftc.net, channel #ovirt , fell free to join us there .
Hi Terry, The engine.log should contain logs regarding ISO files, can you please attach it to the mail, maybe we can find some clues there. Regards, Maor
Hi Terry, The engine.log should contain logs regarding ISO files, can you please attach it to the mail, maybe we can find some clues there.
Regards, Maor
I am attaching what I think you're asking for: /var/log/ovirt-engine/engine.log Near the end of it, I do see this: 2012-02-24 13:49:28,795 INFO [org.ovirt.engine.core.bll.IsoDomainListSyncronizer] (pool-5-thread-48) Finished automatic refresh process for Unknown file type with success, for storage domain id 48a5390f-2f86-485c-8537-b6bc9dd71796. Perhaps that's relevant.
On 02/24/2012 09:37 PM, Terry Phelps wrote:
> Hi Terry, The engine.log should contain logs regarding ISO files, can you please attach it to the mail, maybe we can find some clues there.
Regards, Maor
I am attaching what I think you're asking for: /var/log/ovirt-engine/engine.log
Near the end of it, I do see this:
2012-02-24 13:49:28,795 INFO [org.ovirt.engine.core.bll.IsoDomainListSyncronizer] (pool-5-thread-48) Finished automatic refresh process for Unknown file type with success, for storage domain id 48a5390f-2f86-485c-8537-b6bc9dd71796.
Perhaps that's relevant.
Hi Terry, you right, that is the log, although it could be helpful if the debug mode was enabled there (It can be done by editing the configuration file $JBOSS_HOME/standalone/configuration/standalone.xml and change the xml entry: <logger category="org.ovirt.engine.core.bll"> from INFO to DEBUG)
From what I see, there are no files fetched from VDSM 2012-02-23 15:06:43,465 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand] (http--0.0.0.0-8080-1) FINISH, HsmGetIsoListVDSCommand, return: []
The return list is empty. Im not sure if it was already discussed in this mail thread, but maybe it is also better to check the VDSM log in the hypervisor, or check what does getIsoList verb returns. Regarding the log that you were indicating, I am guessing, some how, there is an unknown file in the DB, that the files in the DB are somehow with file type Unknown, (I can not see the reason for it in the log). but I'm not sure its relevant.
Terry, Like this... [root@node ~]# vdsClient -s 0 getConnectedStoragePoolsList 9775f154-7578-4e22-ae44-4664b298a8cc [root@node ~]# vdsClient -s 0 getIsoList 9775f154-7578-4e22-ae44-4664b298a8cc ------ ISO list with proper permissions only ------- rhel-server-6.2.x86_64-dvd.iso Cheers, Keith On 02/24/2012 03:35 PM, Maor wrote:
On 02/24/2012 09:37 PM, Terry Phelps wrote:
> Hi Terry, The engine.log should contain logs regarding ISO files, can you please attach it to the mail, maybe we can find some clues there.
Regards, Maor
I am attaching what I think you're asking for: /var/log/ovirt-engine/engine.log
Near the end of it, I do see this:
2012-02-24 13:49:28,795 INFO [org.ovirt.engine.core.bll.IsoDomainListSyncronizer] (pool-5-thread-48) Finished automatic refresh process for Unknown file type with success, for storage domain id 48a5390f-2f86-485c-8537-b6bc9dd71796.
Perhaps that's relevant.
Hi Terry, you right, that is the log, although it could be helpful if the debug mode was enabled there (It can be done by editing the configuration file $JBOSS_HOME/standalone/configuration/standalone.xml and change the xml entry:<logger category="org.ovirt.engine.core.bll"> from INFO to DEBUG)
From what I see, there are no files fetched from VDSM 2012-02-23 15:06:43,465 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HsmGetIsoListVDSCommand] (http--0.0.0.0-8080-1) FINISH, HsmGetIsoListVDSCommand, return: []
The return list is empty.
Im not sure if it was already discussed in this mail thread, but maybe it is also better to check the VDSM log in the hypervisor, or check what does getIsoList verb returns.
Regarding the log that you were indicating, I am guessing, some how, there is an unknown file in the DB, that the files in the DB are somehow with file type Unknown, (I can not see the reason for it in the log). but I'm not sure its relevant.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Fri, Feb 24, 2012 at 3:46 PM, Keith Robertson <kroberts@redhat.com>wrote:
Terry,
Like this... [root@node ~]# vdsClient -s 0 getConnectedStoragePoolsList 9775f154-7578-4e22-ae44-**4664b298a8cc
[root@node ~]# vdsClient -s 0 getIsoList 9775f154-7578-4e22-ae44-** 4664b298a8cc ------ ISO list with proper permissions only ------- rhel-server-6.2.x86_64-dvd.iso
Aha! That doesn't show anything:
[root@oravm2 ~]# vdsClient -s 0 getConnectedStoragePoolsList f465251e-5679-11e1-ba81-97917332892e [root@oravm2 ~]# vdsClient -s 0 getIsoList f465251e-5679-11e1-ba81-97917332892e ------ ISO list with proper permissions only ------- [root@oravm2 ~]#
This is a multi-part message in MIME format. --------------090707090001000508090903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, On 02/24/2012 03:58 PM, Terry Phelps wrote:
On Fri, Feb 24, 2012 at 3:46 PM, Keith Robertson <kroberts@redhat.com <mailto:kroberts@redhat.com>> wrote:
Terry,
Like this... [root@node ~]# vdsClient -s 0 getConnectedStoragePoolsList 9775f154-7578-4e22-ae44-4664b298a8cc
[root@node ~]# vdsClient -s 0 getIsoList 9775f154-7578-4e22-ae44-4664b298a8cc ------ ISO list with proper permissions only ------- rhel-server-6.2.x86_64-dvd.iso
Aha! That doesn't show anything:
[root@oravm2 ~]# vdsClient -s 0 getConnectedStoragePoolsList f465251e-5679-11e1-ba81-97917332892e
[root@oravm2 ~]# vdsClient -s 0 getIsoList f465251e-5679-11e1-ba81-97917332892e ------ ISO list with proper permissions only -------
[root@oravm2 ~]#
As Maor suggested, can you please attach the /var/log/vdsm/vdsm.log ? -- Cheers Douglas --------------090707090001000508090903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi,<br> <br> On 02/24/2012 03:58 PM, Terry Phelps wrote: <blockquote cite="mid:CAMUfR_s5Uk26dVJHe6ZyDejYGp+iUe+MTrMFSFD=NpnJCEtu=Q@mail.gmail.com" type="cite"><br> <br> <div class="gmail_quote">On Fri, Feb 24, 2012 at 3:46 PM, Keith Robertson <span dir="ltr"><<a moz-do-not-send="true" href="mailto:kroberts@redhat.com">kroberts@redhat.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Terry,<br> <br> Like this...<br> [root@node ~]# vdsClient -s 0 getConnectedStoragePoolsList<br> 9775f154-7578-4e22-ae44-4664b298a8cc<br> <br> [root@node ~]# vdsClient -s 0 getIsoList 9775f154-7578-4e22-ae44-4664b298a8cc<br> ------ ISO list with proper permissions only -------<br> rhel-server-6.2.x86_64-dvd.iso<br> <br> </blockquote> <div>Aha! That doesn't show anything:<br> <br> [root@oravm2 ~]# vdsClient -s 0 getConnectedStoragePoolsList<br> f465251e-5679-11e1-ba81-97917332892e<br> <br> [root@oravm2 ~]# vdsClient -s 0 getIsoList f465251e-5679-11e1-ba81-97917332892e<br> ------ ISO list with proper permissions only -------<br> <br> [root@oravm2 ~]#<br> <br> </div> </div> </blockquote> As Maor suggested, can you please attach the /var/log/vdsm/vdsm.log ?<br> <br> <pre class="moz-signature" cols="72">-- Cheers Douglas</pre> </body> </html> --------------090707090001000508090903--
On Fri, Feb 24, 2012 at 7:04 PM, Douglas Landgraf <dougsland@redhat.com>wrote:
** Hi,
On 02/24/2012 03:58 PM, Terry Phelps wrote:
On Fri, Feb 24, 2012 at 3:46 PM, Keith Robertson <kroberts@redhat.com>wrote:
Terry,
Like this... [root@node ~]# vdsClient -s 0 getConnectedStoragePoolsList 9775f154-7578-4e22-ae44-4664b298a8cc
[root@node ~]# vdsClient -s 0 getIsoList 9775f154-7578-4e22-ae44-4664b298a8cc ------ ISO list with proper permissions only ------- rhel-server-6.2.x86_64-dvd.iso
Aha! That doesn't show anything:
[root@oravm2 ~]# vdsClient -s 0 getConnectedStoragePoolsList f465251e-5679-11e1-ba81-97917332892e
[root@oravm2 ~]# vdsClient -s 0 getIsoList f465251e-5679-11e1-ba81-97917332892e ------ ISO list with proper permissions only -------
[root@oravm2 ~]#
As Maor suggested, can you please attach the /var/log/vdsm/vdsm.log ?
You got it:
participants (5)
-
Deepak C Shetty -
Douglas Landgraf -
Keith Robertson -
Maor -
Terry Phelps