Recently, I have had a design challenge for my non-profit unmanaged VPS hosting project, klauwd.com. The challenge basically comes down to offering ISO files to the platform’s tenants. In earlier design iterations, I’ve always had a separate datastore on shared storage with separate tenant rights assigned to the datastore. I’ve used products like Nexenta, FreeNAS and HP StoreVirtual (LeftHand OS) virtual appliances to transform local storage to shared storage and carve up multiple datastore from there. This has worked well, but I’ve since changed the design to use VMware VSAN.

Although I’ve had a few kinks on actually implementing VSAN successfully (check out my recent post, Running a Dell PERC with high latency? Check the LSI SMI-S vib!, for more details on horrendous storage performance with the LSI SMI-S vib installed), I did stumble upon this design challenge during my first moments of contact with VSAN. I’ve long thought about a decent solution without overly complex means.

Let me sketch my specific situation a little more clearly:

  • I have multiple ‘tenants’ in vSphere that can only access their own VM folder inside the inventory. They cannot create new VMs or alter the VM configuration. Basically, they can interact with the VM for basic operations like power-on, power-off and use the VM console.
  • They should, however, be able to upload an ISO to a designated datastore and connect the ISO to their VM for Guest OS (re)installation.
  • VSAN only provides a single datastore.

So the issue becomes more clearly: a single datastore to hold both tenant VMs and ISO files? That’s going to be messy, not to mention the off-chance that someone deletes or otherwise negatively interacts with someone else’s VM. And there’s the ‘tenants can see each other’s VMs on the datastore’. Although the klauwd.com platform is community-based and most of the tenants personally know each other, I don’t think it’s anyone’s business being able to see these kinds of details at all.

With that, and the ability to mess interact with files on the datastore, it’s really a requirement to separate ISO files from tenant VMs. This way, I can shield off access to the VM datastore(s) entirely, so no tenant can actually see/browse the VM datastore. Using the standard vCenter roles and permissions, I’m able to completely locked down access to the VM datastore and totally shielded off visibility into that datastore. Even if a tenant’s VM is running on that datastore, they still can’t browse that datastore and see stuff they shouldn’t.

Providing a second datastore for the ISO files is a bit harder. There no way to assign permissions a folder or file level; only at the datastore level or higher.
Using the standard vCenter roles and permissions, I can create a more permissive role for the tenants to upload ISO files, browse the datastore to see if someone else has already uploaded an ISO, etc. This is basically a free-for-all datastore where tenants can do as they please without impacting each other or the platform.

Now, with VSAN, you’re limited to only a single datastore. So even if there’s a sound mechanism in place to provider the correct access to a second datastore, we’re still in need of one. My fellow blogger, Vladan Seget, recently published a post titled ‘How-to use Veeam Backup NFS used for storing ISOs in your VMware vSphere Infrastructure‘. He basically gave me the perfect solution for providing a second datastore to hold the ISO files if you’re running Veeam in your environment.

Let me paraphrase his post and adapt it a little to my situation:

  1. Put ISO files in Veeam vPower NFS folder
  2. This step is optional and only if the vPower NFS datastore hasn’t been mounted yet. You only need to do this once.
    Do a temporary restore of a VM to trigger Veeam to mount the NFS datastore to a host. Using the vSphere Web Client, mount the datastore to remaining hosts in cluster.
    Alternatively, you can use this guide to mount the datastore manually.
    If you’ve done a restore before, Veeam will leave the NFS datastore mounted (but usually only to a single host).
  3. Assign tenant role and permissions to the datastore.
  4. Profit.

This feat can of course be accomplished using local storage (but that’s hard to manage and quirky to use, since the ISO file and VM now have to be on the same host). Alternatively, you can use a storage appliance that presents iSCSI or NFS storage, but many customers are already running Veeam, and why not just use what’s already available? You can make this situation as complex as you see fit: run the Veeam Repository server as a VM on top of VSAN or run it as a physical machine; it doesn’t really matter.

For klauwd.com, I’m running the Veeam server as a VM on local RAID-1 storage. This single Windows box runs the Repository role with vPower NFS, among other roles, to make for a simple backup solution. I’m also using this Windows box as a jump server for some management tooling. With Vladan’s tip, this VM is also hosting the ISO files. A practical side note is that you don’t need to download an ISO from the vendor website first and upload it to the datastore. Just download the ISO directly to the correct folder on the Windows box, and it’s published immediately.

I like the simple elegance of being able to offer a decent solution to the previously mentioned challenge without the need to add more bits to ze klauwd and using what’s already there. Obviously, it has it’s drawbacks, like a tenant potentially DoS’ing my backup server by filling up the filesystem, but this simplicity is a pretty good trade-off for me.