When you are using SPBM but the rest of the world is not (vSAN)

Today I came across an issue I did not immediately think about selecting a data protection or replication solution for a vSAN deployment:

Let us say we have a vSAN datastore as target for a replication (failover target) or a data restore from backup. But what if your data protection or disaster recovery/replication product does not support storage policies?

You might find yourself facing some unexpected problems.

The restore or failover might succeed but your VM files (including VMDKs) are subsequently protected with the vSAN default policy. If you did not modify it, this will result in FTT=1 and FTM=RAID1 (If you are not familiar with FTT and FTM, search for in conjunction with vSAN).

At first glance, this does not look too bad, does it?

Now what if the source VM was protected with FTT=2 and FTM=RAID6?
The restored VM has now less protection with more space consumption and the VM might not even fit on the datastore, even if the clusters are setup identically or even it is the same cluster (in case of a restore).


A VM with a 100GB disk is consuming 150GB  at the source vSAN datastore (with FTT=2 and FTM=RAID6 ) and is able to withstand two host failures. However, it would consume 200GB at the destination datastore (with FTT=1 and FTM=RAID1) as the latter would create two full copies and only one host failure can be mitigated.

Sure you could modify the default policy for this, but what if you have different settings? The beauty of SPBM lies in the fact that you can apply it per disk and re-applying the policy settings for a more complex setup will become messy and error prone.

Now if you ask me for a good example on how to do it:

Veeam shows how to integrate this here.

VMware offers a storage policy mapping in SRM

I/O acceleration at host level – Part II: PrimaryIO appliance deployment

In part 1 I already talked about the basics of I/O acceleration and PrimaryIO as a possible alternative to PernixData FVP. In this (short) post we’ll look at the deployment of the APA appliance.

I recently had the time to download the newest version, GA 2.0, in order to set up a customer Proof of Concept (PoC) .

And I failed at the initial deployment.

Out of the box the OVA would throw an error about an unsupported chunk size.

PrimaryIO – chunk size error with vCenter 6.5

Now I was already sitting in front of a vCenter version 6.5 (with ESXi hosts on 6.0) and as with FVP this is currently not supported for APA (I got the info from support that PrimaryIO targets April/May 2017 for the support).

But since this is a PoC/Lab I didn’t give up easily:

A nice VMware KB article describes  the problem at hand and offers a solution.

Since OVAs are essentially a compressed archive, I used 7zip to extract the files and decided to have look at the appliance definition file (.OVF).

Line 5 and 6 contained the virtual disk definitions and the parameter:


Removing it, the .OVF looked like this after editing:

Gotacha which is also mentioned in the KB article:  You have to delete the .mf file afterswards or at least update the checksums since the content was modified and they no longer match.

I skipped the step of re-creating an .OVA-file since we can use the .OVF and .VMDK-files directly in the FlexClient-deployment wizard. The only remaining adjustment was to relieve the .VMDK-files of their training zeros.

This left me with there three files:

PrimaryIO GA 2.0 files are some adjustments


After that the deployment worked like a charm and my next task was to setup networking since I opted for “fixed IP” within the OVA deployment wizard. Unfortunately the OVF-script does not include a script to set the IP information, however this step is well documented in the manual.

Essentially the APA-appliance is an ubuntu  with enabled “root” login (default password: admin@123) and setting an IP is straightforward.

PrimaryIO – Linux Appliance screen after login

You might adjust additional linux stuff, like syslog and ntp according to your needs.

However, from a security standpoint I am a bit worried.

The appliance is based on Ubuntu 12.04 LTS, which is nearing end of life/support in few weeks– after that there are no more updates.
As you can see, there are initially many updates missing after deployment. I am not sure how the update policy is on the appliance (i.e. can I just use apt-get).

Regarding these questions I will raise this issue with PrimaryIO support and update this article.

Updated info from support:

We do not recommend an apt-get upgrade of the appliance. If you are facing any specific issue – we can help address that. […]
I have a confirmation that the APA 2.5 release scheduled for May 2017 GA will have the latest ubuntu LTS based PIO Appliance.


All right, for a few week I am OK with an “old version”.

Part 3 will go into the APA configuration

I/O acceleration at host level – Part I: Overview & PrimaryIO

In my last to posts I have been rambling about certifications, but it is time to put something useful on this page.

When PernixData released 2.x of FVP they really got the attention of the vCommunity. Lots of posts and happy people all around about two years ago.

For those of you who are not familiar with the topic:
The idea of FVP and similar products is to take the I/O handling as close to the source as possible, which is in case of VMs the ESXi host. You can use memory or flash storage devices as a read or (mirrored-)write cache for your most demanding VMs. (Cached) Requests are instantly answered and load is taken from your storage system. This is especially useful if you have an older model with very little or no flash and/or experience performance problems and you 6want to protect your investment (read: no chance to upgrade hardware any time soon). There are of course other use cases but I’ll try to keep this simple.

But after Nutanix acquired PernixData they essentially buried FVP as a product.
However Nutanix fulfills the support for customers with an existing contract but by now you should have a “plan B” if you need I/O acceleration at host level.
FVP lacks vSphere 6.5 support and I find it hard to believe that great efforts are being made to deliver it anytime soon. (Side note: More than FVP I’ll be missing the PernixData Architect which delivers quite a good view into the storage layer and is very easy to handle.) *UPDATE: I am very sorry, I didn’t give the folks at Pernix/Nutanix the credit they deserve, update is targeted for 04/17 according to support.

So, let’s have a look at a possible alternative:

Last year PrimaryIO offered PernixData FVP customers their Application Performance Accelerator (APA) for VMware at no charge except support costs.

APA uses vSphere APIs for I/O Filtering (VAIO) for their implementation, which  is quite nice in my opinion since this is standardized within the vSphere environment. Here I take the liberty to quote directly from VMware:

VAIO is a Framework that enables their parties (Partners) to develop filters that run in ESXi and can intercept any IO requests from a guest operating system to a virtual disk. An IO will not be issued or committed to disk without being processed by IO Filters created by 3rd parties (source)

Right now there are two supported use cases (caching and replication) and according to VMware

caching will significantly increase the IOPS available, reduce latency, and increase hardware utilization rates (quote from the source from above)

If someone is interested in an overview of currently supported VAIO solutions, you may find it here.

What does APA offer?
According to their technical brief they do not cache randomly or only the most frequented blocks but do this acutally application aware (hence the name, I guess):

Only the most important application components such as frequently accessed tables or indexes that speed up queries are optimized, while less critical elements such as log records, replicas, audit entries, or ad hoc user activity are de-prioritized.

I’m not sure how to track this in the future and verify the claim, so comments are welcome and if I find a way I’ll let you know 🙂

Like FVP they APA offers the possibility to mirror the write cache across hosts which is a must if you take this into production. I’ll need to check if they support fault domains (i.e. two data center).

For a more details on how it works have a look at the VMware blogs where Murali Nagaraj, CTO of PrimaryIO posted about this.


Thank you for your attention, in part 2 I will continue on with the APA appliance deployment


Note: My posts on this topic are in no way sponsored by PrimaryIO.

Personal blog, remember? 🙂