Samba4 with ESXi datastore

[Scott Lovenberg]

On Wed, Dec 2, 2015 at 7:11 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> On Tue, Dec 1, 2015 at 8:50 PM, Scott Lovenberg
> <scott.lovenberg at gmail.com> wrote:
>> On Tue, Dec 1, 2015 at 9:55 PM, bogdan_bartos <admin at blackpenguin.org> wrote:
>>> Hi,
>>>
>>> I was wondering if any of you built this setup. I want to load samba4 onto a
>>> VM hosted in ESXi and I want to give it a datastore from another drive for
>>> the shares. Would this allow for the ACLs to be stored properly, so it works
>>> seamlessly? ESXi tends to format the disks with VMFS, then present the drive
>>> as a virtual disk that would be mounted in the samba machine.
>>>
>>> Any advice?
>>>
>>
>> Hi,
>>
>> I had a couple of setups that were somewhat like what you are
>> proposing.  It'll work fine since the file system beneath is a layer
>> of abstraction; your VM never sees it or knows its there.  You can do
>> even more wild things with your file system layering and it won't
>> cause problems.  All you need for ACLs is to have a file system
>> capable of storing them (and IIRC, that's not even a hard rule - I
>> think at one point ACLs were stored in a TDB a handful of years ago
>> before we had the kernel side stuff we needed), and to turn them on my
>> mounting the file system with "user_xattr,acl".
>>
>> I would however suggest that you use iSCSI without multipathing and
>
> Why do you think multipathing is a problem?
>
I should rescind or modify that statement; ESXi had issues with
multipathing in 5.1 and 5.5 with certain network drivers, but after a
bit of research it seems that might no longer be the case or it was
only the case with certain network bonding modes and multipathing.  In
any event, it should work if you use the right virtual NIC.

>> you do it at the VMWare layer and then hand off the storage to the VM
>> rather than mounting it straight into the VM.  It'll be faster and
>> you'll avoid locking issues that you might get with SMB layered on top
>> of NFS.
>
> What SMB on NFS issues are you thinking of here?
>
> Sure, NFS is used to provide access to the VMDK at the lowest layer,
> but if you are using iSCSI, you have SMB over iSCSI by analogy to your
> statement above.
>

I explained what I meant there poorly too (I wrote the original while
multi tasking poorly).  "Don't re-export NFS via CIFS in the client"
is more in line with what I was trying to say.  Specifically,
overlapping byte range locks would break oplocking.

> However, in both cases it is not really SMB over anything. NFS/iSCSI
> are simply used as a storage access protocol.
>
> Of course, accessing the VMDK as a native (non-iSCSI) disk under ESX
> does not support things like Persistent Reservations or Thin
> Provisioning support (UNMAP etc).
>
> A more important issue will be the FS you use, as that dictates
> whether or not you can support full-sized ACLs.
>

I actually wasn't aware this was still an issue on Linux.  Do we still
fall back to putting ACLs and EAs in a TDB if the file system doesn't
support full sized/any ACLs? I'm guessing that also means some file
systems can't support hosting the sysvol natively.


-- 
Peace and Blessings,
-Scott.