-----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
-----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-----