Samba4 with ESXi datastore

[Richard Sharpe]

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?

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

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.

>Avoid file storage all together if you can and have the
> entire path be block storage until you're at your VM's file system
> level.  You'll curse yourself a lot less if you minimize layering.
>
> Now that you have that advice, I'm going to go ahead and tell you to
> keep the Samba box on hardware and virtualize everything else.  IOPS
> and network IO are expensive and the security protocols used in Samba
> are hardware clock sensitive.  The only reason to put your Samba
> server in a VM is for isolation and ease of backup/redeployment.  I'd
> suggest that you do put a second domain member server in a VM for
> redundancy, but make the primary a hardware build and make sure it has
> an Intel NIC.
>
> That being said, I'm sure if you ask around here enough you'll find
> someone that violently disagrees with that; perhaps even with good
> reason.
> --
> Peace and Blessings,
> -Scott.

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)