Hello Dear VMWare enthusiasts,
Let's imagine following hypothetical scenario. Probably it sounds weird, but please don't ask me why I even think about it
What if I create a special storage policy backed by shared flash storage. This SP would be used explicitly for VM Home and VM swap objects/files but not for VMDKs?
That is hundreds of VMs will have VM Homes including swap files on this specific SP and VMDKs on multiple other SPs.
What potentially negative factors to expect from this scenario on vSphere 6.x environments based on a) VMFS b) AllFlash vSAN ?
Please share your thoughts!
Firstly, you posted this in the wrong sub-forum. This needs to get moved to vSAN.
Second
please don't ask me why I even think about it
why are you even thinking about this?
This SP would be used explicitly for VM Home and VM swap objects/files but not for VMDKs
Unless those VMs are actively using the swap file...which generally you should never see nor want to see...this would be a complete waste of all-flash media. So see the first question at the top.
You could certainly do this, but again, it begs the question as to why. A much better use is to put the VMDKs on that all-flash policy, or better yet, put the whole VMs on flash and let vSAN sort it out from there which it's good at doing.
Thanks for Your reply.
Firstly, you posted this in the wrong sub-forum. This needs to get moved to vSAN.
Why? It's not vSAN related. I've mentioned vSAN as one of the options. The same can be done with traditional VMFS volumes.
I think it's more related to SBPM or Storage in general.
Unless those VMs are actively using the swap file...which generally you should never see nor want to see...this would be a complete waste of all-flash media. So see the first question at the top.
You could certainly do this, but again, it begs the question as to why. A much better use is to put the VMDKs on that all-flash policy, or better yet, put the whole VMs on flash and let vSAN sort it out from there which it's good at doing.
It's not about performance or storage resource allocation. It is about having separate Storage Policies for VMDKs and HM Home. It could be all on flash storage or even on the same datastore if that's supported.
I know technically that is possible, but would it be ok to run this in production?
It's not about performance or storage resource allocation. It is about having separate Storage Policies for VMDKs and HM Home.
But what's the point of having separate storage policies for those different objects? If it's not about performance or storage utilization (capacity), why do this? What objective does it achieve? It sounds like all it's doing is complicating things, and complexity should always be avoided if it adds no benefit.
Ok. It is difficult to explain, but I will try. When you use vSphere as a part of vCloud Director environment You provide storage resources to end users in form of SPs with allocated available capacity. (If allocation model is applied). Like "gold_flash_tier"=600GB. In this scenario each VM takes space from assigned SPs for VMDKs and VM home objects. If the VM has VMDK=500G and RAM=64GB, this will reserve 564+ GB from that gold_flash_tier. This starts to be a problem (resource provisioning, management, billing) when You have a hundreds of VMs with lots of RAM, 3-4 different SPs and several self-service users for the tenant making independent changes.
I do realize I'm trying to solve one complexity bringing another. That's probably not the best approach.
Anyway thanks for your attention. This is why I'm here - for an advice or opinion.
When it comes to vCD, I can't really advise there because I'm not familiar with it. Many others here are. But, again, there has to be a reason for increasing complexity. If you're not solving a problem in exchange for more complexity, it's just a waste of effort. On the technical side, you can set a reservation on the VM's memory which will reduce or eliminate the swap file taking up the amount equal to its provisioned memory, but there are severe trade-offs there. Make a data-driven decision when you decide to change those defaults and split up a VM amongst multiple storage policies.