Deploying the Actifio vCenter Plugin to VMware VCSA 6.0

This is just a short tip to help get the Actifio vCenter Plugin uploaded to your VCSA appliance, so you can start the installation process. By default if you try to scp the install file you will find an error such as the following: Unknown command: 'scp' 1. Login via SSH to the vCenter Server Appliance on port 22, I would normally use the root account here: $ ssh [email protected] VMware vCenter Server Appliance 6.0.0 Type: vCenter Server with an embedded Platform Services Controller Password: Last login: Mon Jun 22 00:15:14 UTC 2015 from 10.0.0.51 on ssh Last failed login: Mon Jun 22 02:38:16 UTC 2015 from 10.0.0.51 on ssh:notty There was 1 failed login attempt since the last successful login. Last login: Mon Jun 22 02:38:17 2015 from 10.0.0.51 Connected to service     * List APIs: "help api list"     * List Plugins: "help pi list"     * Enable BASH access: "shell.set --enabled True"     * Launch BASH: "shell" Command> 2. As per the motd, you need to start the shell so run the command shell.set --enable True Then run the following command to get into the shell shell Next, run the following command to change the default shell chsh -s "/bin/bash" root Now you can scp the Actifio VCP file to the vCenter Server Appliance. FileZilla or command line scp are your friend here (example below): scp -P 22 ActifioVCPInstaller_unix_6_1_2.sh [email protected]:/tmp/. Now go back to the VCSA shell and change the default shell back chsh -s /bin/appliancesh root Now you can run the installer with the following command sh /tmp/ActifioVCPInstaller_unix_6_1_2.sh And now follow the bouncing ball to get your Actifio vCenter Plugin installed. Click to share article:ShareLinkedInTwitter

vCenter authentication fails, even though you know you have the right password!

At one of my customer accounts we were experiencing an issue in one of the customer’s sites. Here is the scenario of the problem. 1. We Tested Authentication with the AD service account setup for Actifio. Authentication failed, even though we knew we had the right login & details. We also ensured we were using the correct syntax DOMAIN\Username to login. 2. Login to the remote vCenter from customers Desktop (which points to a site domain controller in the local site) as the Actifio AD service account. Authentication Works fine, and vCenter is opened and objects displayed. 3. Test creating a snapshot and creating a new VM from vCenter. All works ! 4. Test Authentication in Actifio with the AD service account. Auth failed again. But why ? We know we have the correct details, and it can login via vCenter using the same API calls Actifio would make to login. So, my process of elimination begins. Can we remove the Active Directory as the problem somehow ? Yes, vCenter 5.x and above uses a Single Signon (SSO) process, which can have local accounts. So here is what we tried: 1. Change the service account in actifio, from the AD service account to be the “[email protected]” SSO account (vCenter 5.0 U1), and enter the correct password. Auth Works ! 2. Snapshots work in Actifio, and all is working. Happy Days. So what does this tell us the root cause is ? My thoughts are it’s one of the following. a) Possibly time sync is out between the customers remote site vCenter and the remote site Domain controller. b) The customers remote site Domain Controller is out of sync or not correctly working anymore with Active Directory in the local site. c) The SSO configuration for VMware and allowing authentication against the customers domain is not setup correctly. I am leaning towards (c) as the primary candidate for the problem, with potentially (a) too (as we had seen this another time at the customer site). Either way, this issue is not caused by Actifio or a result of bad code, but it affects us. So knowing how to troubleshoot SSO vCenter authentication is important with the way we authenticate against vCenter in 5.x and above. Hopefully this saves some time for others to help pin-point the potential issue. The key point is remove AD out of the equation, use the SSO admin account, and see if authentication is still not working. Once the root cause of the AD auth issue in the remote site is debugged, we can then go back to using the limited rights AD service account. Click to share article:ShareLinkedInTwitter