In part 1 of this series I talked about some of the basic pros and cons in moving the VM swapfile and the guest OS virtual memory to a dedicated datastores.
Now, let’s start using some of VMware goodies.
I had a few comments on Linkedin coming from Didier Pironet saying:
“I see two concerns here, disk space usage and disk IO usage.
If you’re concerned by the disk space usage, you have two options:
1. Reserve as much memory as possible and your virtual machine’s .vswp will shrink in size.
2. Within the Guest OS, set the lowest possible page file.“
I would like to address it. The .vswp file size is the size of VM allocated memory minus the VM reserved memory.
A VM with 8GB configured and 2GB reserved memory will have 6GB .vswp file, so that is a good way putting your swap on a diet but what about large environments which cannot afford or don’t use DRS and don’t have the ability to use resource pools?!
The only way to do it is to configure each VM individually without having any real dynamic resources management in terms of reservations and limits, which can end up causing greater problems.
As for the guest OS page file, like I mentioned in part 1, there are many different approaches regarding Windows or Linux virtual memory. Sometimes each system needs to be addressed separately and differently.
Leveraging the use of Profile-Driven Storage
Profile-Driven Storage is a great feature we can use in our advantage in order to create the separation infrastructure.
Basically, the idea is to give each datastore a unique storage capability. That way, we can create a mechanism which will tell the VM where each of its VMDKs will be stored so everything will fall in order.
The profiles can be created automatically using VMware vStorage APIs for Storage Awareness (VASA) which exposes the storage array LUNs capabilities. Profiles created by VASA are un-selectable when it comes to assign a profile to a datastore by the admin and for that, in the following step-by-step guide, I will be using User-Defined Storage Capabilities.
First, on the vSphere client go to Home > VM Storage Profiles in order to enable it on a cluster or on a host.
Before creating a new VM Storage Profile we need to add a new storage capability. Go to Manage Storage Capabilities > Add. Create two capabilities named OS-W2008 and pagefile with an intuitive description.
As you can see, eventually you will get a list of all your user-defined capabilities.
Go to Create VM Storage Profile, create two new profile and match the appropriate storage capabilities for each one.
Remark: It is possible to assign more than one storage capability to a datastore.
In my lab, I’ve created two new datastores named V5.1-Lab-W2008-NFS-01 which will use to store Windows 2008 virtual machines and V5.1-Lab-pagefile-NFS-01 for storing any kind of Windows virtual machine’s pagefile VMDKs. Right click on each datastore and assign it with a User-Defined Storage Capability from the list.
Go to datastore configuration tab to see its new details. Notice how there is no System Storage Capability, which is because I didn’t add VASA capability in my lab environment.
Now that we have set our datastore to profiles relationship we are ready for the VM configurations side of things.
On the next parts for this series I will be showing how to change the VM swapfile location, configure your VM in order for them to match to profile compliance, configure your VM templates and perform the deployment process manually and automatically with the use of PowerCLI scripting.