Skip to main content
  • EN

We have an existing Veeam environment as a service provider and using Cloud Connect.  With this we currently host cloud backups and replication for tenants, which works fine.  We also have VMware vCloud Director integrated.

 

We are just now implementing CDP into this same environment.  When CDP is installed into the environment, Veeam creates a new storage policy in vSphere named “Veeam CDP Replication”.  This storage policy has a requirement defined to “enable host based rules”, and the single rule that is enabled is “Replication” and Provider veecdp, which is the I/O filter name.

 

For reasons I cannot work out as of yet, this storage policy will only see one of our datastores as compatible, and this datastore happens to be the local direct attached storage of one of the ESXi hosts in the cluster, not storage on both hosts.  All other datastores show as incompatible.  Our other datastores that I would like to use are NFS volumes on Linux hosts.  I have set this up in a lab and demo environment, and there the storage policy does see some, but not all, of our NFS shares on a NetApp.

 

What happens now is, if I create a new tenant account and create it as VMware Cloud Director Account, then Veeam will only allow the tenant to be assigned the storage policy from VMware as their storage, I cannot seem to pick my preferred storage explicitly.  If I create a new tenant account as a Standalone Account, then I can pick any storage in my environment that I want.

 

So my challenge is, how can I create a new tenant as a VMware Cloud Director Account and be able to assign them the proper storage I need to in my environment?

Following simply for the fact that I’m not using VCD but want to know.

That storage policy - what comprises its policy structure? Is it a tag based placement? If so, is it using tags that your storage is tagged with?

The policy is only based on host based rules, no tags or anything specifically storage related.  And again, this is the policy that Veeam creates automatically when the I/O filter is installed.  I’ll attached a screenshot of that part of the policy as well as the actual rule it’s processing.

 

 

 

I suspect you need to change that storage policy to also include the same way you present your NFS shares. You are likely doing that by tags, but you know your environment best. If its done by tags, then add the tab based placement rules on the new veecdp policy and have it use the same tags as your NFS shares.

Thank you for the suggestion.

The issue is that Veeam will only present storage policies that have the replication veecdp provider enabled as a feature.  When the tenant connects to request the resource pool, it activates this I/O filter as part of the process to replicate this data.

If I disable this replication requirement of CDP, then Veeam will no longer present this as a destination option when the tenant is setting up their CDP policy, so implicitly no storage will be presented to the tenant because none will have this replication component enabled.

Also, since the storage polices work off of an AND calculation, if I were to also enable tags to this same policy, so have both replication veecdp and tags both enabled, then I have none of our storage matching, because none of our storage will have both the veecdp match AND the storage tags that we normally use.

Found and fixed the issue with VMware/Broadcom support.  I also better understand what Veeam is doing now with its I/O filter plug-in.

Apparently, vCenter and the ESXi hosts already have I/O filters built in.  It seems that Veeam is simply activating or leveraging these in a way for its own replication jobs.

The issue we ran into, however, is that when the certificates were renewed on the ESXi hosts, they didn’t properly synchronize with vCenter, so vCenter, which is what Veeam communicates with, saw the certificates as invalid for I/O filters, thereby not allowing Veeam or anything else to access any external storage using I/O filters.  The one other odd thing is that even though both hosts were showing certificates as expired, one host did show its storage as online and one offline.  I don’t know why this was and it wasn’t really the important part, since we weren’t interested in their local storage, so we didn’t spend time troubleshooting this issue of online and offline local storage.

VMware support provided a KB to synchronize the certificates between ESXi and vCenter.  We did that and everything started working.  I’ll share the KB and screenshot of the vCenter location below.  The screenshot is in the vCenter Web UI and on the vCenter server itself.

https://knowledge.broadcom.com/external/article/318887/certain-iofilter-providers-are-showing-a.html

 

 

Wow….interesting cause here.  Thanks for following up and sharing your findings here!

Comment


Terms & Conditions