No. They have all logfiles now and they are investigating the problem. But I'm in contact with them.
No response from support since 07.04. They also have my logifles.
Yes, busy with them now...
In my case after removing the plugins and restarting the webclient without the VDP2 plug-in I see after rebooting an appliance that a directory is created. But the directory is named: C:\ProgramData\VMware\vSphere Web Client\vc-packages\vsphere-client-serenity\com.vmware.vdp2-18.104.22.168
In the directory the right 6.1.2.war is there (<pluginPackage id="com.vmware.vdp2" version="6.1.2" name="VDP 6.1" description="vSphere Client VDP plugin" vendor="VMware">)
So the correct plug-in is loaded in the webclient but still hanging...
I currently have a case with me where 6.1.2 vdp grays out after the connect. My colleague has the same with 6.1.1
validate the following:
1. Port connectivity verification
2. Name resolution for vdp
3. Restart tomcat service
4. Verify time sync and restart VMware tools on vdp
service vmware-tools restart
5. Re register to vCenter
If all these steps are implemented and still the connect fails with the hung gray screen, then you are in the same place as I am..still working on it
Yes, been there done that :/ I think these cases need to be escalated to engineering... Because back-ups ain't running also...
My case: 16959042704
Little more info after testing:
1. I migrated my VDP network to vDS and it stays grayed out on connect in web client
2. Migrated the VDP networking to standard switch and it connected immediately.
Are we running distributed switches?
Correct, after switching to VSS I can connect to the appliance again...
During the upgrade to 6.2.1 I lost my back-upjob with attach existing disks method.
Now trying to create a new job for tonight...takes long for submitting the job? Still waiting or I'm not patient enough.
Well a little step further now... Now is the questing what is causing this behaviour
Backup job creation should be quick.
What is causing the behavior? That's a good question. Unfortunately I do not have the answer right away, let me dig in more into this.
I recently ran into this issue with VDP webclient not loading at a customer of mine. vCenter and PSC recently was updated to 6.0 U1. I believe its a vCenter or PSC permission issue and not specifically a VDP issue.
We looked at the webclient vergo logs at the time attempting to open the VDP webclient. Looks like the web client has an issue with com.vmware.vim.binding.vim.dvs.PortConnection which has to do with distributed switches.
[2016-04-06T17:50:42.280-05:00] [INFO ] http-bio-9443-exec-14 org.springframework.flex.servlet.MessageBrokerHandlerAdapter Channel endpoint vdp-amf received request.
[2016-04-06T17:50:42.367-05:00] [INFO ] http-bio-9443-exec-14 org.springframework.flex.servlet.MessageBrokerHandlerAdapter Channel endpoint vdp-amf received request.
[2016-04-06T17:50:42.382-05:00] [ERROR] http-bio-9443-exec-14 Endpoint.AMF Cannot create class of type 'com.vmware.vim.binding.vim.dvs.PortConnection'.
- flex.messaging.MessageException: Cannot create class of type 'com.vmware.vim.binding.vim.dvs.PortConnection'. Type 'com.vmware.vim.binding.vim.dvs.PortConnection' not found.
Moving VDP from distributed switches to standard switches did get it to work and the errors disappeared in the vergo log. vCenter can still be connected to a distributed switch. Backup jobs continued to work when the webclient would not load.
It looks similar to this KB https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2125229 which is why I'm thinking its a vCenter or PSC permissions issue due to the upgrade. At this point we will probably wait for VMWare support to resolve the issue because for us moving VDP to a standard switch is an alright work around.
We also have an odd behavior with some of the roles displaying differently. For example there is a role called "inventorhyservice.tagging.taggingadmin" instead of "Tagging Admin". Might be related.
Informative. Let me get the analysis going and I can try correlating to what we are seeing in your virgo logging.
I am experiencing the exact same issue, figured I'd poke around here before submitting a ticket.
I'm on vCenter 6.0 U2/ESXi 6.0 U2 and VDP 6.1.2, all VMs use 9.10.5 VMware Tools on HW Profile 11
If I switch to a Standard Switch things work but on a Distributed Switch the Web Client hangs on connecting, I have found I can create backup jobs against a vSAN datastore but not against a shared storage array. Not sure if local storage works!
Glad to see I'm not alone.
I can do everything with the VDP on the VSS except creating a simple back-upjob with 1 VM :/
Showing the logs/reports, running a manual integrity check and deleting a restore point is not a problem. Rebooted the appliance twice allready.
Are there any logs for these actions? And where are they located on the VCS?
Feedback from VMware support: VDP 6.1.x doesn't work with Virtual Distributed Switch !
They were able to reproduce the bug.
Next step is to open a ticket to EMC support (since VDP is a EMC solution just rebranded by VMware) , but this might take time ...
Perhaps if all of you guys open SR regarding this problem it will reduce the resolution time ?
Workaround is to use Standard vswitch but in my case this is very complicated since we have a full dvswitch environment (due to LACP usage).
vdr-server.log has these information.
It's going to look something like this for a successful create:
2016-04-15 18:55:47,371 INFO [http-nio-8543-exec-10]-rest.BackupService: Create backup job qwerty
2016-04-15 18:55:47,387 INFO [http-nio-8543-exec-10]-services.BackupJobManagementServiceWS: VCenterClient fqname="/192.168.1.1/192.168.1.1" name="192.168.1.1" cid="d03a58d99b282b9c7c6cb9c6367ff23394f0f014" os="N/A" ver="Unknown" init-time="2016-04-04 00:00:00.0 (1459708200000)" last-contact-time="2016-04-07 00:00:00.0 (1459967400000)" plugins= vcenter-port=443 vcenter-user="vsphere.local\Suhas"
2016-04-15 18:55:47,469 INFO [http-nio-8543-exec-10]-job.JobServiceImpl: Setting the window start time: Fri Apr 15 20:00:08 IST 2016
2016-04-15 18:55:51,102 INFO [http-nio-8543-exec-10]-ddr.DdrDatasetServiceImpl: Successfully Set DDR DatasetOptions (enabled=false, index=0) On Dataset "qwerty"
2016-04-15 18:55:51,102 INFO [http-nio-8543-exec-10]-job.JobServiceImpl: Created Backup Dataset "qwerty"
2016-04-15 18:55:51,184 INFO [http-nio-8543-exec-10]-services.BackupJobManagementServiceWS: Client name=CentOS7 uuid=5039665b-4899-9c00-1695-e42ff9d4eda2 vcc=VCenterClient fqname="/192.168.1.1/192.168.1.1" name="192.168.1.1" cid="d03a58d99b282b9c7c6cb9c6367ff23394f0f014" os="N/A" ver="Unknown" init-time="2016-04-04 00:00:00.0" last-contact-time="2016-04-07 00:00:00.0" plugins= vcenter-port=443 vcenter-user="vsphere.local\Suhas" vmpath=[Protected_LUN] CentOS7/CentOS7.vmx guestid=centos64Guest guestfullname=CentOS 4/5/6/7 (64-bit)
2016-04-15 18:55:51,587 INFO [http-nio-8543-exec-10]-services.BackupJobManagementServiceWS: Schedule: 0
is your backup create failing? If so does it display any error in GUI?
And what does vdr_server log state?