With release 10.3.2 and later, by default if a VM is no longer detected present in a VMWare environment, an alert will be generated to notify users it has been removed from schedules.
Starting with release 10.3.2, when a VMWare VM is dropped from a backup schedule because it is no longer detected as available/present in the VM host, an alert with the text "VM %s removed from schedules due to vMotion or connection loss" is generated.
This is a normal process and typically requires no action by the user. The alert is informational as we do not attempt to back up VMs that are not detected in VMWare as that would generate continuous backup failures unless resolved.
If the VM was removed from inventory and re-added manually, and is later re-added and retains the same VMWare UUID, then users will have to re-add the VM back to schedules manually. This is true even if the "automatically include new VMs" option is enabled as per our inventory this is not a "new" VM.
Customers who do not want this behavior, and instead would prefer VMs to remain in schedules and fail backups if the VM is no longer present also have this option.
In the UI, navigate to: Configure > Appliances > Select Appliance > Edit > Advanced Tab > General Configuration > locate the "vprotect" section of the INI editor. Change the value pruneSchedules=0. After this change, VMs that are no longer present will have to be manually deleted from jobs. This option is available in 10.3.2 and later releases only.
At the launch of any job, as well as nightly during normal inventory sync operations, VMWare inventory is reviewed. New VMs detected are added to the Unitrends Database, and old VMs that are no longer detected present are marked as "current = f" in our database.
This can be due to a VM being migrated between 2 different vCetner environments (removing the VM from the old and adding it to a different vcetner), a VM that is moved between 2 hosts where a vCetner has not been added to a unitrends appliance that manages the, manual removal of a VM from VMWare's inventory (even if it still occupies a datastore), a VM that had a UUID change (VMs are inventoried by UUID as different VMs can have the same name), or because a VM was restored overwriting/replacing the original VM.
When this occurs, Unitrends no longer has an association to back up the old VM and automatically removed it from backup schedules. VMs are not automatically removed from Cold or Hot copy jobs when this occurs.