D81

Hi everybody!
Big update here, after checking the issue with a work colleage, we have found the source of the problem... 
First of all we have performed a test by manualy attach of the testpackage.vmdk to the packaging VM and we have confirmed that the disk was correctly attached, also when doing the manual disk attach the App Volumes Agent has automaticaly started the pacaking process. So we performed a complete installation of the Notepad++ application as if we were packaging it. However after rebooting the packaging VM to end the package process, we realize that the App volumes manager still didnt detected the package, instead it was showing the "PACKAGE" option to start the package process as if nothing had happened on the packaging machine. We have also noticed that on the vCenter there were no tasks acctions or alerts when we launched the initial package attachment.
So at that point we suspected that the issue was related with the communication between App Vol manager and the vCenter or the ESXs. 
Then we check configuration of the vCenter on the App Vol Manager and we disabled this feature to avoid the direct  mounting of the packages by the ESXI servers 

And voilà! that fixes the issue!!!
So at this point we are able to perform the packages normaly without problem only if we disable the "Mount ESXi" feature. However we would like to know why that "mount ESXi" feature is not working cause as far as we know it allows a better performance and thus we would like to reenable it on the future.
Could anybody provide us with the requirements to use that feature? For example:
Which ports should be available on the ESXs and from which source? Should the iCMP be available? Notice that the "ping" is not allowed on this LAN for security reasons  
Thanks
PS. we have also feedback from the support ticket, the Omnisa engineer has detected a GPO that is blocking the attachment of disks so he has asked us to move the Packaging machine VM to an OU without GPOs and test it there. I will post the results later...
 

I found the solution:
In our case the SQL database was implemented on a Failover Cluster with Always on Availability Group (there are two SQL servers). I performed a manual failover from SQLserver1 to SQLserver2, then I reboot the App Vol manager and I was able to log into the manager without issues.

I performed a new failover to SQLserver1 to test it and it still works fine so I assume maybe the loadbalancer didnt worked fine.
EDIT: as @Robin Harmsen mentioned, you should also have AG listener configured instead of the Failover Cluster name during the database configuration on the app volume manager