Re: ESXi NFSv4.1 client id is nasty

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Tue, 19 Jun 2018 11:11:08 +0000
Steve Wills wrote:
On 06/18/18 17:42, Rick Macklem wrote:
>> Steve Wills wrote:
>>> Would it be possible or reasonable to use the client ID to log a message
>>> telling the admin to enable a sysctl to enable the hacks?
>> Yes. However, this client implementation id is only seen by the server
>> when the client makes a mount attempt.
>>
>> I suppose it could log the message and fail the mount, if the "hack" sysctl isn't
>> set?
>
>I hadn't thought of failing the mount, just defaulting not enabling the
>hacks unless the admin chooses to enable them. But at the same time
>being proactive about telling the admin to enable them.
>
>I.E. keep the implementation RFC compliant since we wouldn't be changing
>the behavior based on the implementation ID, only based upon the admin
>setting the sysctl, which we told them to do based on the implementation ID.
Well, without one of the hacks (as head currently is) the mounts always fail,
so ESXi mounts failing is a feature of the "unhacked" server.
(The ReclaimComplete failure fails the mount.)

>Just an idea, maybe Warner's suggestion is a better one.
Yes, I think Warner has the right idea, although logging a message w.r.t. the
ReclaimComplete failure (which fails these mounts) when the hacks are turned
off sounds like a good one to me.

>Steve

rick
Received on Tue Jun 19 2018 - 09:11:10 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC