[...] 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?

-----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(a)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 _______________________________________________ Users mailing list Users(a)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(a)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