This section lists issues known in Veeam MP 8.0 – Update 3 for VMware.
Microsoft Operations Management Suite compatibility issues
Under rare circumstances, Operations Manager connected to Microsoft Operations Management Suite may cause Veeam MP objects to become unmonitored. This behavior will be accompanied by 1215 events written into the Operations Manager log. This is a known Microsoft compatibility issue, and Microsoft is currently working on the solution.
If you encounter the issue, we recommend that you contact Veeam Support.
Capacity Planning for Azure Hybrid Cloud report output may list some VMs twice
Two Microsoft Azure VM sizes — A10 and D13 — are almost identical besides a small difference in the hardware specifications. If a VM fits both sizes, the Capacity Planning for Azure Hybrid Cloud report output will show the VM twice.
Absent Path property in the Traffic Lights widget
Supporting SQL stored procedures on the SQL back-end have been significantly re-factored by Microsoft and now work more reliably and much faster, however the current version lacks path information. Even if you configure the Traffic Lights widget to display the Path property, dashboards will still show no data for it.
In a future release, Veeam will improve the Traffic Lights widget architecture to display Path properties regardless of data obtained from the supported SQL stored procedures.
Drill-down option may not work in Capacity Planning for Azure Cloud report
The Capacity Planning for Azure Cloud report included in the Veeam Capacity Planning for Hybrid Clouds MP provides an opportunity to click numbers in the output table to drill down to the list of VMs that matches profiles and to check performance data for these VMs. However, if the number of VMs is too big (>200), the drill-down option will not work and you will get the following error: ‘The value of parameter 'Object' is not valid. (rsInvalidParameter). Invalid URI: The Uri string is too long.’
This is a known MS SQL Server 2012 SP1 issue.
Non-default collation settings for SQL cause Data Warehouse errors after import of Veeam MP
If you are using a non-default SQL Collation that is not supported by Ops Mgr, after installation of Veeam MP you may receive errors, such as: ‘Cannot resolve the collation conflict between ‘SQL collation’, ‘SQL_Latin1_General_CP1_CI_AS’ and ‘Latin1_General_CI_AS’ in the equal to operation.’
This is not a Veeam MP issue, although it is exposed by the reporting features in Veeam MP. The root cause is an unsupported configuration for the Ops Mgr Data Warehouse DB.
To avoid this issue, make sure that the supported collation is specified for Ops Mgr and Data Warehouse databases when installing Ops Mgr. It is also required that the collation is configured identically between the following databases and the SQL instance(s) in which they reside:
For existing installations it may be required to port/reinstall Ops Mgr to use a supported SQL collation configuration.
For a list of collations supported by Ops Mgr, see:
|•||Ops Mgr 2012 SP1 system requirements at technet.microsoft.com/en-us/library/jj656654.aspx|
|•||Ops Mgr 2012 R2 system requirements at technet.microsoft.com/en-us/library/dn249696.aspx|
Issues adding VMware server with disabled TLS 1.0
If you disable TLS 1.0 on an ESXi host or vCenter Server and try to connect to the server using the Veeam UI, Veeam MP will fail to establish the connection and you will get the following error: ‘The underlying connection was closed: An unexpected error occurred on a send’. This is an expected behavior for situations when TLS 1.0 and SSLv3 are disabled on the target server.
Before you try connecting to the VMware server, check that all machines that run the Virtualization Extensions Service and Veeam Collector service have Microsoft .NET Framework 4.5.2 installed. To force the .Net assemblies to use more secure encryption, follow the instructions provided in this VMware KB article.
Maintenance Mode synchronization failure
In case a Veeam Collector is installed on an Ops Mgr agent-managed machine that communicates with the Management Server through a gateway server, the Management Server will be unaware of hosts that were placed in the Maintenance Mode in the VMware vSphere Client.
When the Maitenance Mode Synchronization script is running, the Collector uses port 5724 to connect to the Management Server. The problem is that the gateway server uses port 5723. to connect to the Management Server, and this divergence will cause the script to fail.
To work around the issue, after you put a host in the Maintenance Mode in the VMware vSphere Client, do the same in the Ops Mgr console.
Unknown VM swap files
NetApp best practices for VMware recommend that you keep VM swap files on an alternate datastore. However, if you try to change the swap file location to other than the default one, vCenter Server 5.5 and earlier will consider the file to be unknown. That is why the Veeam MP Scan Datastore for Unknown Files task and the Veeam VMware: Datastore Unknown Files Analysis monitor will also capture the file as unknown, and the unknownFilesGB metric will report incorrect values.
To work around the issue, follow the instructions provided in this VMware KB article Storing a virtual machine swap file in a location other than the default in ESX/ESXi.
Veeam Relationship History, Storage vMotions History and vMotions History reports may not work or work slowly
The Ops Mgr Data Warehouse DB may accumulate huge amounts of discovered objects and relationships between them. If you have many management packs installed and frequent discoveries running, in 3-5 years the Relationship Table may include millions of records.
Please contact Veeam Customer Support to hotfix performance of Veeam Relationship History, Storage vMotions History and vMotions History reports by narrowing down the scope of objects available for reporting.
Unexpected Consumed Memory metric values for vSphere cluster reports
Under certain circumstances, if you choose to split host clusters into multiple monitoring jobs to allow more flexible load-balancing, the VMCluster-memory \ memoryUsedMB metric may report incorrect values.
To work around the issue, disable the SplitClusters option and try redistributing monitoring load across Collectors.
COS partition monitoring deprecated
In Veeam MP 8.0, COS partition monitoring on ESX hosts has been deprecated. Please contact support for additional information.
Hardware information not collected via CIM-XML
In the new version, the default method of hardware status monitoring uses vCenter hardware alarms. After you upgrade to Veeam MP 8.0, hardware monitoring using CIM over XML will be disabled.
To learn how to enable monitoring through CIM-XML, see Veeam MP Resource Kit Guide.
Host performance data collection skipping intervals
In some cases no performance data is obtained from vCenter for a specific ESXi host for a given performance interval.
Veeam is working with VMware SDK support on the root cause of this issue. In version 8.0, Veeam MP handles this situation and generates a VP510 event driving a Monitor in the Ops Mgr. When the problem is resolved, Veeam MP notifies that ESX host performance data was successfully collected with the VP511 event.
Veeam MP plug-in for vCenter not compatible with VMware plug-in requirements
In previous versions, Veeam UI could be integrated directly into the VMware vSphere client. This was accomplished by registering the UI as a plug-in with the vCenter server. Starting with Veeam MP v8, there is no such a possibility since the plug-in is no longer compatible with the current VMware plug-in requirements.
vCenter Connection Failover issues
Veeam MP for VMware includes the vCenter Connection Failover feature which allows host and VM monitoring to continue, even if vCenter Server goes offline. The feature eliminates vCenter Server as a SPoF (Single Point of Failure) for monitoring data. This feature has the following limitations:
Veeam UI does not show connected VMware servers
If you open Veeam UI when vCenter connection failover and/or failback for a vCenter Server with several hundreds of hosts is performed, Veeam UI may not be able to display connection changes promptly. As a result, you will see no servers under the Connected VMware Servers tree on the VMware Servers tab. To fix the issue, log off and then log in back.
Alerts for inactive direct-to-host connections remain after vCenter connection failback
After the vCenter Connection Failover feature has performed failback (removing direct-host connections and returning to using a vCenter connection), alerts that were triggered for failed direct-to-host connections may be shown as unresolved in the Ops Mgr console for up to one hour, even if the host connection in vCenter is restored.
This is due to the one hour schedule for rediscovery of the connection configuration for the Veeam Extensions Service. Any alerts for direct-host connections will disappear when the direct-host connections are removed from Ops Mgr on the next discovery cycle. The discovery interval for the Veeam Virtualization Extensions Service connection topology can be modified by overriding the discovery rule Veeam Virtualization Extensions for System Center Topology discovery.
vCenter connection failover does not work if any managed host is in Lockdown mode
If Lockdown mode is enabled for any host managed by vCenter Server, there is no way to connect to the ESX(i) host directly. As a result, the Virtualization Extensions Service will not be able to create direct-to-host connections during vCenter Connection Failover.
vCenter connection failover will utilize all Collectors in monitoring group
When Virtualization Extensions Service fails over to direct-to-host connections, the direct-to-host collection jobs are ‘load-balanced’ among all Collectors in the monitoring group. Collectors which were Inactive may become loaded with host Monitoring Jobs, and hosts may be monitored by different Collectors than were used for the vCenter connection.
Datastore monitoring disabled for direct-to-host connections
Datastore monitoring for direct-to-host connections is disabled by default, due to possible issue with the vCenter Connection Failover feature. When a vCenter failover occurs connections are automatically created direct to all hosts. When using directly-connected hosts there are limitations in the host API, which reports shared datastores as multiple duplicate datastores for every host connection. The performance metrics for such datastores are inaccurate, as individual hosts are not aware of other host activities on shared storage. This duplication of datastores can also cause the monitoring load on Collectors and the Ops Mgr system to increase significantly. For these reasons datastore monitoring is automatically disabled by default for direct-host connections and it is not recommended to enable it when using the vCenter Connection Failover feature.
If monitoring of direct-to-host connections and their attached datastores is a requirement (for example for remote office/branch office situations, where hosts are not part of a vCenter) then datastore monitoring can be enabled by using the advanced MonitorDatastoresForDirectHost setting in the Veeam Virtualization Extensions UI. This setting can be applied to a separate monitoring group in the Veeam UI which holds only direct-to-host connections, allowing flexibility to use both direct-to-host and vCenter connection methods in one environment. For more information, see the Operations Guide, vCenter Connection Failover section.
Controlling vCenter connection failover during planned vCenter maintenance
If you plan to perform maintenance on the vCenter Server, however Veeam failover to direct-host connections is not desired, it is recommended to set the Veeam link to vCenter or vSphere Host object in maintenance mode. This will prevent the Veeam VMware: Connection lost to VMware vCenter Server monitor from triggering the failover script. For details on putting vSphere objects in the maintenance mode in Ops Mgr, refer to the Operations Guide, Maintenance Mode Synchronization section.
Alternatively, if you wish to pro-actively trigger the Veeam failover to direct-host connections before the vCenter actually goes offline, you can manually force the failover using the in-context ‘Force failover to to direct-Host connections’ task to enable monitoring via direct-to-host connections. Then you can set the Veeam link to vCenter or vSphere Host object in maintenance mode which will prevent unwanted failback.
Account unable to access the Veeam Virtualization Extensions Service during vCenter connection failover
For the vCenter Connection Failover feature to function, a powershell script must run in context of the Ops Mgr Agent Action account which will reconfigure the monitoring targets using the Veeam powershell interface (VE Shell). If the default Action Account for the Ops Mgr agent on the Veeam Virtualization Extensions Service machine does not have access to the Veeam VEShell (PowerShell interface), you may see the following error: ‘[User ID] account unable to access the Veeam Virtualization Extensions Service’. The error can occur for any Agent Action account that cannot access Veeam VEShell, including LocalSystem.
To fix the issue, the account specified as default Agent Action Account should be added to the Veeam Virtualization Extensions Users local group on the server running the Veeam Virtualization Extensions Service. Please keep in mind that the vCenter connection failover feature will not work if you use Local System as the default Agent Action Account, that is why adding Local System to the group is not desired. In this case, change the Agent Action Account to be a domain user account, and add this account to the local group. Note that this account should also be an Administrator of the local server.
The account may also be unable to access the Veeam Virtualization Extensions Service during failover because you have the Enterprise license edition. Only Enterpise Plus edition supports vCenter connection failover.
VMs rediscovered with different IDs after vCenter connection failover
When vCenter conection failover occurs, VMs will be re-discovered with a new ID, as the vSphere API used when connecting direct to hosts does not provide the same ID as a vCenter connection. This will result in VMs being re-discovered effectively as ‘new’ VMs in Ops Mgr terms. Note however that the display name for such VMs in Ops Mgr will be the same — only the underlying Operations Manager ID will be different. This will be transparent for normal monitoring situations, but some gaps may be visible in historical reporting once vCenter is restored and failback has occurred.
Veeam UI suffers degraded performance with very high number of direct-host connections
If the Virtualization Extensions Service manages direct connections for more than 300 vSphere hosts, the Veeam UI application may suffer degraded performance. As a result, Veeam UI may become unresponsive, or operations may be performed with delays. If the Virtualization Extensions Service manages more than 500 vSphere hosts, you may observe problems and errors with representation of the VMware Servers connections hierarchy in Veeam UI.
If you work with a large number of direct-connected vSphere hosts (for example, if the vCenter Connection Failover feature has been triggered), it is strongly recommended to use the Veeam VEShell interface for configuring and managing the Veeam Virtualization Extensions Service, since VEShell does not experience the same performance problems as Veeam UI. For details on the available powershell commandlets for managing the Veeam Virtualization Extensions Service, see the Veeam VEShell Reference.
Overprovisioned Storage report may display negative values for overprovisioned VMs
For thin-provisioned VMs, vSphere may report that used space values are higher than the allocated space values. This may happen in several cases: memory swapped out to a datastore, VM being migrated or suspened. For such VMs, the Datastores. Overprovisioned Storage report may show negative overprovisioning values.
This is a known vSphere API issue. Normally, in large infrastructure such VMs should not be visible in the list of top 5 over-provisioned VMs.
vCenter-targeted monitors contain duplicate entries in State Change Events table
If you configure multiple monitoring jobs for one vCenter Server and assign these jobs to different Veeam Collectors, all Collectors will generate events and trigger monitors. That is why the monitor State Change Events table will have multiple entries with the same events.
Veeam UI plugin does not appear in vSphere Web Client
When you integrate Veeam UI directly into the VMware vSphere client by registering the UI as a plugin with the vCenter server, the plugin does not appear in the VI Client UI.
During initial discovery Ops Mgr shows GUIDs instead of datastore names
Under certain circumstances, when the environment has multiple Veeam Collectors, and datastore discovery on the Collector that runs the datastore monitoring job is delayed, then Ops Mgr may show datastore GUIDs instead of datastore names.
This issue will be resolved automatically within 4-24 hours when discoveries from all Collectors have completed. Alternatively, you can manually re-launch the discovery process and initiate a topology rebuild. To do so, in the Veeam UI go to the Veeam Collectors tab and click the Rebuild Full Topology link.
Alerting on unconnected NICs for vSphere hosts
If a vSphere host NIC is not connected to any vSwitch or Distributed vSwitch, Veeam MP for VMware will not monitor its state. Monitoring will only start when NIC is added to a switch.
5-minute interval required in vCenter Statistics settings
The default 5-minute setting in vCenter for statistics collection (VI Client - Administration – Statistics) should not be changed. This interval is required for Veeam MP for VMware data collection.
Unknown files analysis issues
The following issues related to unknown files analysis are known to exist:
|•||Running the Scan Datastore for Unknown Files task against inactive datastores can cause task failure.|
|•||For datastores with no registered VMs, the UnknownFilesGB metric value is returned as ‘0’.|
|•||During VM migration process, there can be two copies of VM files while the VM is registered on one host only. The host where the VM is not registered might report VM files as garbage files. This will result in the UnknownFilesGB metric showing inaccurate value and the Veeam VMware: Datastore Unknown Files Analysis alerts triggered for affected datastores.|
|•||Storage devices with hardware deduplication may report unknown files values incorrectly. That is why the Veeam VMware: Datastore Unknown Files Analysis monitor is disabled by default for Virtual Volumes, VSAN datastores and NFS datastores.|
|•||The Veeam VMware: Datastore Unknown Files Analysis monitor tracks space taken on datastores by files unknown to vCenter. Some 3rd-party solutions can replicate, backup or copy VM files without registering them in vCenter.|
To resolve the issue, override the monitor by increasing the UnknownFilesGBThreshold value to prevent the monitor from firing unwanted alerts. You can also simply disable the monitor for the necessary datastores. The Veeam VMware: Datastore Free Space Analysis monitor will continue to work and report on free space left on the datastores.
Veeam VMware Collector may be unable to retrieve host statistics via CIM
If the time on a Veeam Collector is not synchronized with the time on monitored ESX(i) hosts, the Collector will be unable to gather hardware data from the hosts via CIM.
To learn how to verify time synchronization across an ESX/ESXi host environment, see the VMware KB article.
Tracking audit events in drill-down for Host Security Profile report
Due to differences in the methods Ops Mgr uses to store events versus the methods used to store object properties, the Host Security Profile report may not display all expected audit events when you drill down to a specific change. This can occur due to synchronization issues around discovery and update of the Host Security Profile object (which happens once daily) and the storing of associated security change events (which happens in real-time).
To view all host security profile audit events, click the Total number of changes link under the host name. This link will always display all security events captured in the reporting period.
Health Service recommended configuration monitor stays in Warning state after recovery action
After Veeam MP for VMware is installed, the Veeam VMware Collector: Health Service recommended configuration monitor runs a recovery action — a script that adjusts registry configuration settings for the Ops Mgr Health Service on Collector servers. After the script is performed, the Health Service (Microsoft Monitoring Agent Service) is restarted. Note that automatic restart only occurs when the Collector is installed on a server with Ops Mgr Agent — not an Ops Mgr Management Server.
In some cases, the script may fail to to restart the Health Service (Microsoft Monitoring Agent); as a result, the monitor will stay in the Warning state. To resolve the issue, restart the Microsoft Monitoring Agent service manually.
OpsMgr Shell Module or Snap-in not found
On the Ops Mgr Management Server, the Maintenance Mode synchronization script may fail with the following error: ‘MaintenanceMode.ps1 : OpsMgr Shell Module or Snap-in not found.’
To resolve the issue, install PowerShell 3.0 and reboot. If this does not resolve the issue, install the Operations Console on the Management Server.
Same datastore under different vCenter Servers or Datacenters is recognized as 2 objects
If the same datastore is connected to different Datacenters within one vCenter Server or if the same datastore is connected to different vCenter Servers, it is recognized as two datastore objects in Operations Manager. Note that VMware do not recommend this configuration. Veeam MP for VMware treats such datastore as two separate datastores with completely different sets of properties and metrics. Although some metrics are the same (for example, size or free space), most performance counters will be different.
Orphaned objects and sporadic error ‘Unable to open Veeam VMware Event log’
During the normal Veeam MP for VMware discovery process, some vSphere objects may be temporarily unmanaged and their management will reside on an Operations Manager Management Server. When trying to run Veeam workflows for such objects, the Management Server will attempt to open the Veeam VMware Event log. If there is no Veeam VMware Collector installed on the MS, the following error will be observed: ‘The Windows Event Log Provider is still unable to open the Veeam VMware Event log on computer ‘<OpsMgr Manager Server Name>’.’
When the Veeam MP discovery process is finished, all vSphere objects will have been ‘claimed’ for management by a Collector and the errors on the MS should no longer appear.
Veeam Collector may skip events from directly-connected ESX(i) host after reboot
The vSphere API has a known issue when connecting directly to an ESX(i) host that the Event ID counter is reset when the host is rebooted. The Veeam Collector uses this Event ID to internally track and filter events for delivery to Ops Mgr, and the reset of this counter causes the event filtering to fail and events may be skipped.
If direct-host connections are used (for example during the vCenter Failover feature), then the following procedure should be followed if a host is rebooted.
|1.||Stop Veeam VMware Collector service where the rebooted host is monitored.|
|2.||Locate the sidebar.xml file in the Data folder of the Veeam Collector installation directory.|
|3.||Locate the <field name='eventTracker' type='System.Collections.Hashtable' > tag in the file.|
|4.||Inside the tag, locate and delete the single line for the rebooted host server (this line will hold host name and a cached event ID counter, for example ‘esx-prod2:329999’).|
|5.||Start Veeam VMware Collector service.|
Login using Windows credentials not supported when Veeam UI is on a separate server
When the Veeam Virtualization Extensions Service and Veeam Virtualization Extensions UI are installed on different machines, login to the UI using Windows credentials fails with the error: ‘System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.’ This is because Microsoft IIS does not pass authentication data across the two machines.
You can access the UI by re-entering valid account credentials (a member of the Veeam Virtualization Extensions Users group).
No Access permission restrictions not supported
Partially-restricted vCenter permissions for the VMware connection account are not supported — that is, excluding vSphere hosts/clusters/VMs from monitoring by having ‘No Access’ permission in vCenter for those specific objects is not supported. The VMware connection account must have minimum read-only access to the entire vCenter VI-tree.
To remove hosts/clusters from monitoring, use the Veeam Virtualization Extensions UI, VMware Servers tab, and clear the check boxes for the clusters or hosts that should not be monitored.
To remove specific virtual machines from monitoring, use overrides on the Veeam MP discovery rules. For details, see Operations Guide, section Discovery Filtering.