I successfully upgraded our two VDP 6.1.8 instances to 6.1.9, but having issues upgrading them to 6.1.10 now. The ISO mounts, but in the UI under 'Upgrade' it's showing "To upgrade your VDP appliance, place connect a valid upgrade ISO image to the appliance." The avinstaller.log shows no activity since upgrading to 6.1.9, so I tried restarting the avinstaller service (avinstaller.pl --restart), but when it tries to stop the service it shows a Java "Connection refused" exception. Anyone know what could be happening or how to debug further? Thanks.
The thing here is using VDP in 2018...
Why are you upgrading such a painful appliance?
Please, be aware that there a tons of better solutions than that, hope anyone can help you but if you still using this, you should be moving to another backup solution.
VMware is discontinuing VMware vSphere Data Protection (VDP)
vSphere Data Protection: End of Life - Partner News - VMware Blogs
Yea, I know. We are planning to move to another solution in early 2019, however, a critical security bulletin was just released by VMware last week for VDP in which the fix is to upgrade to 6.1.10.
BTW, after more digging, it appears the upgrade from 6.1.8 to 6.1.9 may not have been successful after all. I noticed the client plugins are still showing version 6.1.8 for VDP and there is no VDP icon/menu item on the vsphere web client. I'm thinking it may be related to (https://thevirtualist.org/vsphere-data-protection-not-accessible-after-upgrade-to-6-1-6/ ), but I'm not seeing the same errors in the virgo log file. The only errors I'm seeing in my virgo log file are a few of these exceptions:
[2018-11-28T08:28:44.523-08:00] [ERROR] http-bio-9443-exec-97 c.vmware.vise.vim.commons.mks.tomcat.RemoteConsoleMessageInbound Error writing to the socket java.net.SocketException: Connection closed by remote host^M
at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1565)^M
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:71)^M
at com.vmware.vise.vim.commons.mks.tomcat.RemoteConsoleMessageInbound.onBinaryMessage(RemoteConsoleMessageInbound.java:122)^M
at org.apache.catalina.websocket.MessageInbound.onBinaryData(MessageInbound.java:62)^M
at org.apache.catalina.websocket.StreamInbound.doOnBinaryData(StreamInbound.java:178)^M
at org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:135)^M
at org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(UpgradeProcessor.java:88)^M
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:633)^M
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)^M
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)^M
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)^M
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)^M
at java.lang.Thread.run(Thread.java:748)^M
Actually, that was the solution. I followed the steps outlined at that link and the VDP plugin now shows 6.1.9, the VDP icon is back, and the two VDP instances are accessible again from the web client's VDP interface.
Hello,
From what I've been tracking Vmware Data Protection for years, it's normal for it to run into problems, so I've changed my backup solution.
Frank Aguilieri