Re: [Users] Can't add NFS domain
Damiano, Thanks a lot for your answer. I just got vdsm compiled and installed on fresh FC17 (installed with live cd), used your 3.4.9 FC16 kernel. Yes, now, engine can add it as host, great. But engine still can't add NFS domain. Any idea what is happening? Regards, -- John Xu On Mon, 2012-09-03 at 23:52 +0200, Damiano Verzulli wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Il 03/09/2012 05:47, Changsen Xu ha scritto:
Damiano,
How did you install the kernel-3.4.9-2.fc16.x86_64.rpm ?
with:
rpm -ivh kernel-3.4.9-2.fc16.x86_64.rpm
on the node. Actually my node was a Fedora 17 installed as such.... and not the ovirt-iso-image (BTW: I thought you were working on an FC17, not on a ovirt-node-image, sorry!).
Installed it on the node iso from ovirt.org ? Those iso are read only, even if I "mount -o remount,rw /", I still can't persist the kernel files, system complained out of space.
Sorry. As I said, I worked on standard FC17.
Or did you install on fresh/empty Fedora Core ?
exactly
Then how did you install the vdsm?
by following this guide:
http://wiki.ovirt.org/wiki/OVirt_3.1_release_notes#Fedora_Host
In detail, starting with a "running" fedora:
# yum localinstall http://ovirt.org/releases/ovirt-release-fedora.noarch.rpm
Afterwards, right after installing the Engine (on a different host, in my case), simply adding the "ovirt FC17 node" as a new node from the web-interface of the "engine", the "adding process" will take care of the setup of all the software components.
So, in the end, it will be the engine that will connect to the node and launch, on the node, the setup (yum install....) of all the required RPMs (...that are provided by the repository provided by the initial ovirt-release-fedora.noarch.rpm.
HTH.
I just can't find any detailed guide on internet.
Ovirt is a great project, really. But unfortunatly it lacks documentations.
Bye, DV
- -- Damiano Verzulli e-mail: damiano@verzulli.it - --- possible?ok:while(!possible){open_mindedness++} - --- "Technical people tend to fall into two categories: Specialists and Generalists. The Specialist learns more and more about a narrower and narrower field, until he eventually, in the limit, knows everything about nothing. The Generalist learns less and less about a wider and wider field, until eventually he knows nothing about everything." - William Stucke - AfrISPA http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlBFJoQACgkQcwT9fsMT4SzRogCfYtYJwB+eyCC5LbNUV4ltOu2W Ye4AnRPA36VdnuGc3JZ6jjk4WfCGwlHd =Eiip -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (so you've switched discussing on the list. Ok. Let's go this way) Il 04/09/2012 07:45, Changsen Xu ha scritto:
[...] I just got vdsm compiled and installed on fresh FC17 (installed with live cd), used your 3.4.9 FC16 kernel. Yes, now, engine can add it as host, great. But engine still can't add NFS domain. Any idea what is happening?
To correctly troubleshoot your issues, please, ensure you're following _all_ the steps suggested here: http://wiki.ovirt.org/wiki/Troubleshooting_NFS_Storage_Issues In particular: 1 - confirm your node are running the 3.4 kernel (uname -a), as installing the new kernel is not enough. Such kernel _must_ be running; 2 - confirm that your NFS server is configured: - to default to NFSv3 (refer to above wiki page); - with a correct export (refer to above wiki page). Please pay attention to the need of having, on the NFS server, a USER with UID 36. Best if related username is "vdsm"; 3 - confirm that your FC17-nodes can "see" the exported mounts from the NFS server by running, on the nodes: # showmount -e <ip_addr_of_the_NFS_server> When all of above steps are confirmed, you can start troubleshooting file-permission issues. In detail: 4 - from the FC17-node, manually mount the NFS share with something like: # mount -t nfs <NFS_server_ip_addr>:<NFS_mount> <temp_mount_point> (in my case: mount -t nfs 10.0.49.14:/storage/NFS /tmp/test_nfs) and then try to: - write a file in /tmp/test_nfs: # touch /tmp/test_nfs/test_file.txt and rightafter check, on the NFS server, its ownership/permission. As said in the wiki page, the test_file.txt should be owned by "UID 36" user and should have 755 file-permission 5 - when the all of this is (succesfully) completed, you can retry adding the NFS ISO-domain from the Engine. BTW: if a previous addition attempt failed, in my case I needed to manually remove, on the NFS server, the file/directory structure that previous attempts generated. HTH Bye, DV P.S.: please, let's stick discussing on the list. - -- Damiano Verzulli e-mail: damiano@verzulli.it - --- possible?ok:while(!possible){open_mindedness++} - --- "Technical people tend to fall into two categories: Specialists and Generalists. The Specialist learns more and more about a narrower and narrower field, until he eventually, in the limit, knows everything about nothing. The Generalist learns less and less about a wider and wider field, until eventually he knows nothing about everything." - William Stucke - AfrISPA http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBFnVkACgkQcwT9fsMT4SwmhACfeWD0UQkgxuap3Ao9/D8Xn/Qk DYYAnRVlo/goqOflOhxImMM2QYFhGJ9e =zuCR -----END PGP SIGNATURE-----
On Tue, 2012-09-04 at 08:19 +0200, Damiano Verzulli wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
(so you've switched discussing on the list. Ok. Let's go this way)
Il 04/09/2012 07:45, Changsen Xu ha scritto:
[...] I just got vdsm compiled and installed on fresh FC17 (installed with live cd), used your 3.4.9 FC16 kernel. Yes, now, engine can add it as host, great. But engine still can't add NFS domain. Any idea what is happening?
To correctly troubleshoot your issues, please, ensure you're following _all_ the steps suggested here:
http://wiki.ovirt.org/wiki/Troubleshooting_NFS_Storage_Issues
In particular:
1 - confirm your node are running the 3.4 kernel (uname -a), as installing the new kernel is not enough. Such kernel _must_ be running;
2 - confirm that your NFS server is configured: - to default to NFSv3 (refer to above wiki page); - with a correct export (refer to above wiki page). Please pay attention to the need of having, on the NFS server, a USER with UID 36. Best if related username is "vdsm";
I've playing with this problem for several days, done every step I can find on internet, just can't figure out why. On my node/host, if I "su - vdsm -s /bin/bash", I can't never use mount. It always complained only root can use mount. I can use root to mount nfs server manually, but just can't add NFS domain in the engine side. I tried both ovirt 3.1 and 3.0, neither worked. I used /etc/hosts file on all engine, hosts, nfs server. Should I use DNS ?
3 - confirm that your FC17-nodes can "see" the exported mounts from the NFS server by running, on the nodes: # showmount -e <ip_addr_of_the_NFS_server>
When all of above steps are confirmed, you can start troubleshooting file-permission issues. In detail:
4 - from the FC17-node, manually mount the NFS share with something like: # mount -t nfs <NFS_server_ip_addr>:<NFS_mount> <temp_mount_point> (in my case: mount -t nfs 10.0.49.14:/storage/NFS /tmp/test_nfs) and then try to: - write a file in /tmp/test_nfs: # touch /tmp/test_nfs/test_file.txt and rightafter check, on the NFS server, its ownership/permission. As said in the wiki page, the test_file.txt should be owned by "UID 36" user and should have 755 file-permission
5 - when the all of this is (succesfully) completed, you can retry adding the NFS ISO-domain from the Engine. BTW: if a previous addition attempt failed, in my case I needed to manually remove, on the NFS server, the file/directory structure that previous attempts generated.
HTH
Bye, DV
P.S.: please, let's stick discussing on the list.
- -- Damiano Verzulli e-mail: damiano@verzulli.it - --- possible?ok:while(!possible){open_mindedness++} - --- "Technical people tend to fall into two categories: Specialists and Generalists. The Specialist learns more and more about a narrower and narrower field, until he eventually, in the limit, knows everything about nothing. The Generalist learns less and less about a wider and wider field, until eventually he knows nothing about everything." - William Stucke - AfrISPA http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlBFnVkACgkQcwT9fsMT4SwmhACfeWD0UQkgxuap3Ao9/D8Xn/Qk DYYAnRVlo/goqOflOhxImMM2QYFhGJ9e =zuCR -----END PGP SIGNATURE-----
On 09/07/2012 07:03 AM, Changsen Xu wrote:
On Tue, 2012-09-04 at 08:19 +0200, Damiano Verzulli wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
(so you've switched discussing on the list. Ok. Let's go this way)
Il 04/09/2012 07:45, Changsen Xu ha scritto:
[...] I just got vdsm compiled and installed on fresh FC17 (installed with live cd), used your 3.4.9 FC16 kernel. Yes, now, engine can add it as host, great. But engine still can't add NFS domain. Any idea what is happening?
To correctly troubleshoot your issues, please, ensure you're following _all_ the steps suggested here:
http://wiki.ovirt.org/wiki/Troubleshooting_NFS_Storage_Issues
In particular:
1 - confirm your node are running the 3.4 kernel (uname -a), as installing the new kernel is not enough. Such kernel _must_ be running;
2 - confirm that your NFS server is configured: - to default to NFSv3 (refer to above wiki page); - with a correct export (refer to above wiki page). Please pay attention to the need of having, on the NFS server, a USER with UID 36. Best if related username is "vdsm";
I've playing with this problem for several days, done every step I can find on internet, just can't figure out why.
On my node/host, if I "su - vdsm -s /bin/bash", I can't never use mount. It always complained only root can use mount.
I can use root to mount nfs server manually, but just can't add NFS domain in the engine side. I tried both ovirt 3.1 and 3.0, neither worked.
I used /etc/hosts file on all engine, hosts, nfs server. Should I use DNS ?
only root can use mount. vdsm uses sudo or vdsm super process (don't remember if it was changed already) to do the mount. when you do it from the engine, it asks vdsm to do it. can you share the vdsm logs from trying to add the nfs storage domain via the engine?
3 - confirm that your FC17-nodes can "see" the exported mounts from the NFS server by running, on the nodes: # showmount -e <ip_addr_of_the_NFS_server>
When all of above steps are confirmed, you can start troubleshooting file-permission issues. In detail:
4 - from the FC17-node, manually mount the NFS share with something like: # mount -t nfs <NFS_server_ip_addr>:<NFS_mount> <temp_mount_point> (in my case: mount -t nfs 10.0.49.14:/storage/NFS /tmp/test_nfs) and then try to: - write a file in /tmp/test_nfs: # touch /tmp/test_nfs/test_file.txt and rightafter check, on the NFS server, its ownership/permission. As said in the wiki page, the test_file.txt should be owned by "UID 36" user and should have 755 file-permission
5 - when the all of this is (succesfully) completed, you can retry adding the NFS ISO-domain from the Engine. BTW: if a previous addition attempt failed, in my case I needed to manually remove, on the NFS server, the file/directory structure that previous attempts generated.
HTH
Bye, DV
P.S.: please, let's stick discussing on the list.
- -- Damiano Verzulli e-mail: damiano@verzulli.it - --- possible?ok:while(!possible){open_mindedness++} - --- "Technical people tend to fall into two categories: Specialists and Generalists. The Specialist learns more and more about a narrower and narrower field, until he eventually, in the limit, knows everything about nothing. The Generalist learns less and less about a wider and wider field, until eventually he knows nothing about everything." - William Stucke - AfrISPA http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlBFnVkACgkQcwT9fsMT4SwmhACfeWD0UQkgxuap3Ao9/D8Xn/Qk DYYAnRVlo/goqOflOhxImMM2QYFhGJ9e =zuCR -----END PGP SIGNATURE-----
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 07/09/2012 06:03, Changsen Xu ha scritto:
[...] 2 - confirm that your NFS server is configured: - to default to NFSv3 (refer to above wiki page); - with a correct export (refer to above wiki page). Please pay attention to the need of having, on the NFS server, a USER with UID 36. Best if related username is "vdsm";
I've playing with this problem for several days, done every step I can find on internet, just can't figure out why.
On my node/host, if I "su - vdsm -s /bin/bash", I can't never use mount. It always complained only root can use mount.
You _cannot_ "mount" as "vdsm" users, as generally only "root" can mount. The "vdsm" will do the mount as "root", thanks to "sudo" features. In my case, for example, the vdsm log say: - -------------------------- Thread-694::DEBUG::2012-09-02 22:23:06,813::__init__::1164::Storage.Misc.excCmd::(_log) '/usr/bin/sudo - -n /bin/umount -f -l /rhev/data-center/mnt/10.0.49.14:_mnt_STORAGE_NFS' (cwd None) - -------------------------- Even if the mount will be done as "root", it will be the "vdsm" user that will "write" to the NFS share. Hence, on the NFS-server-side, you need "write permission" for user with UID-36. That's why you have to take care, on the NFS-server side, that: - - the NFS server is configured to map _all_ "anonymous" (see below) write request as if they are made by (local to the NFS server) UID 36 => cfr. anonuid/anongid option for /etc/exports file (see "man exports"). Consider that, if I'm right, a write request is considered "anonymous" if it is not possible to reverse-lookup the UID traveling inside NFS-write request, into a "username" mapped within the (local to the NFS server) /etc/passwd file. and to avoid any potential misunderstanding: - - the NFS server has a local user with UID 36 defined (as well as a local gid with GID 36). This is not strictly required, but helps during troubleshooting activities, as you see the same username both within the client, and the server. To add further complexity... let me add that when I had NFS problems on my side....
I can use root to mount nfs server manually, but just can't add NFS domain in the engine side.
... I was: - - perfectly able, with exactly the very-same "sudo" command, and from the "vdsm" account, to manually mount the NFS-share (again: with cut-and-paste from the log-file); - - afterwards, to "read/write" to the NFS share, with "vdsm" user/permission. Even during the few-seconds interval, after the "ADD ISO DOMAIN" click, and before the "error" showed in the web-interface, I correctly saw the NFS-remote filesystem, locally mounted on the ovirt-node. So, technically, the node is perfectly able to mount the NFS share. But then, unfortunatly, something goes wrong and... the web-app due to this, take care to "umount" the NFS. I'm supposing this as, magically, the previously mounted NFS-share, simply "disappeared" :-( This, at least, in my case. Bye, DV - -- Damiano Verzulli e-mail: damiano@verzulli.it - --- possible?ok:while(!possible){open_mindedness++} - --- "Technical people tend to fall into two categories: Specialists and Generalists. The Specialist learns more and more about a narrower and narrower field, until he eventually, in the limit, knows everything about nothing. The Generalist learns less and less about a wider and wider field, until eventually he knows nothing about everything." - William Stucke - AfrISPA http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBJuU0ACgkQcwT9fsMT4Sw8OgCgk9PNV5kBmTvVZWqcmcubmbXl yEIAn0OJQ9qcKkfIcFkHtOn5cVzoXYN3 =pWup -----END PGP SIGNATURE-----
I somehow got the ovirt 3.0 work! It might be related to my /etc/exports file on the NFS server (not 100% certain though), it seems I need add both ip and machine name to it ( machine names are from /etc/hosts on every machine): /mnt/sdb1 192.168.0.*(rw,sync,no_subtree_check,all_squash,anonuid=36,anongid=36) *.ovirt(rw,sync,no_subtree_check,all_squash,anonuid=36,anongid=36) Thanks for all you guys' help. -- John Xu On Fri, 2012-09-07 at 11:07 +0200, Damiano Verzulli wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Il 07/09/2012 06:03, Changsen Xu ha scritto:
[...] 2 - confirm that your NFS server is configured: - to default to NFSv3 (refer to above wiki page); - with a correct export (refer to above wiki page). Please pay attention to the need of having, on the NFS server, a USER with UID 36. Best if related username is "vdsm";
I've playing with this problem for several days, done every step I can find on internet, just can't figure out why.
On my node/host, if I "su - vdsm -s /bin/bash", I can't never use mount. It always complained only root can use mount.
You _cannot_ "mount" as "vdsm" users, as generally only "root" can mount.
The "vdsm" will do the mount as "root", thanks to "sudo" features. In my case, for example, the vdsm log say: - -------------------------- Thread-694::DEBUG::2012-09-02 22:23:06,813::__init__::1164::Storage.Misc.excCmd::(_log) '/usr/bin/sudo - -n /bin/umount -f -l /rhev/data-center/mnt/10.0.49.14:_mnt_STORAGE_NFS' (cwd None) - --------------------------
Even if the mount will be done as "root", it will be the "vdsm" user that will "write" to the NFS share. Hence, on the NFS-server-side, you need "write permission" for user with UID-36. That's why you have to take care, on the NFS-server side, that:
- - the NFS server is configured to map _all_ "anonymous" (see below) write request as if they are made by (local to the NFS server) UID 36 => cfr. anonuid/anongid option for /etc/exports file (see "man exports"). Consider that, if I'm right, a write request is considered "anonymous" if it is not possible to reverse-lookup the UID traveling inside NFS-write request, into a "username" mapped within the (local to the NFS server) /etc/passwd file.
and to avoid any potential misunderstanding:
- - the NFS server has a local user with UID 36 defined (as well as a local gid with GID 36). This is not strictly required, but helps during troubleshooting activities, as you see the same username both within the client, and the server.
To add further complexity... let me add that when I had NFS problems on my side....
I can use root to mount nfs server manually, but just can't add NFS domain in the engine side.
.. I was:
- - perfectly able, with exactly the very-same "sudo" command, and from the "vdsm" account, to manually mount the NFS-share (again: with cut-and-paste from the log-file); - - afterwards, to "read/write" to the NFS share, with "vdsm" user/permission.
Even during the few-seconds interval, after the "ADD ISO DOMAIN" click, and before the "error" showed in the web-interface, I correctly saw the NFS-remote filesystem, locally mounted on the ovirt-node. So, technically, the node is perfectly able to mount the NFS share.
But then, unfortunatly, something goes wrong and... the web-app due to this, take care to "umount" the NFS. I'm supposing this as, magically, the previously mounted NFS-share, simply "disappeared" :-(
This, at least, in my case.
Bye, DV
- -- Damiano Verzulli e-mail: damiano@verzulli.it - --- possible?ok:while(!possible){open_mindedness++} - --- "Technical people tend to fall into two categories: Specialists and Generalists. The Specialist learns more and more about a narrower and narrower field, until he eventually, in the limit, knows everything about nothing. The Generalist learns less and less about a wider and wider field, until eventually he knows nothing about everything." - William Stucke - AfrISPA http://elists.isoc.org/mailman/private/pubsoft/2007-December/001935.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlBJuU0ACgkQcwT9fsMT4Sw8OgCgk9PNV5kBmTvVZWqcmcubmbXl yEIAn0OJQ9qcKkfIcFkHtOn5cVzoXYN3 =pWup -----END PGP SIGNATURE-----
On 04/09/2012, at 3:45 PM, Changsen Xu wrote: <snip>
Thanks a lot for your answer. I just got vdsm compiled and installed on fresh FC17 (installed with live cd)
You probably won't get that to work, because the live cd has the bad kernel. Installing a new kernel on it doesn't work either (without huge effort maybe?). You would be better off to do a "normal" installation of Fedora 17, install the old kernel there, then add VDSM to that. Hope that helps. ;) + Justin -- Aeolus Community Manager http://www.aeolusproject.org
participants (4)
-
Changsen Xu -
Damiano Verzulli -
Itamar Heim -
Justin Clift