Credentials test on Linux based VM's fail since Update 2

[apronk]

The credentials test in a job for virtual machines fail on Linux credentials.
For instance the linux credentials to Ubuntu VM's, the credentials to a VMware vCSA VM or a FreeBSD based VM.
The test will always fail since the upgrade to Update 2 (8.0.0.2021).

[nefes]

Could you please select any linux VM in "test credentials" window and check, which exact step is failed?

[apronk]

You can't test credentials per VM, there is only one button "Test credentials" which will check all the VM's in the job.
And all the Linux or BSD based ones will fail.

But the error message for Linux: 8-5-2015 08:42:19 :: Guest OS sles11_64Guest is not supported.
And for BSD: 8-5-2015 08:42:19 :: Guest OS freebsd64Guest is not supported.

And on another evironment it wil, say this about the vcenter appliance:
8-5-2015 8:48:29 :: Testing SSH credentials for: root Error: The negotiation of encryption algorithm is failed
But here is no mention of not supporting the sles11_64Guest.

[apronk]

Any idea's ?

[foggy]

Arend, please open a case with our technical support. Logs should tell the reason of why credentials test fails.

[AndreZEUS]

Hello,
i tested it. if i want to backup my vCenter with the right credentials it says:
16.05.2015 13:35:48 :: Find target VM on Host 172.21.48.58
16.05.2015 13:35:50 :: Validating guest agent availability for the VM
16.05.2015 13:35:50 :: VM is powered on.
16.05.2015 13:35:50 :: Guest OS state is Running
16.05.2015 13:35:50 :: VMware Tools status is Ok
16.05.2015 13:35:50 :: Host: 172.21.48.58; IP address: 172.21.48.58
16.05.2015 13:35:50 :: VMX file name: [VMFS-LES1] VMware-vCenter-Server-Appliance/VMware-vCenter-Server-Appliance.vmx
16.05.2015 13:35:50 :: IP address: 172.21.48.58
16.05.2015 13:35:50 :: Guest OS: sles11_64Guest
16.05.2015 13:35:50 :: Guest OS sles11_64Guest is not supported.


All success messages, only the last one is with a red X.
The backup is fine but with a warning. Just:
"16.05.2015 13:23:18 :: Failed to create indexer. Details: Guest credentials for the VM are not specified. "

But i think its fine.
Just want to share it

[foggy]

I don't thins this is fine, so opening a case is recommended.

Btw, there's a KB article regarding this one:

8-5-2015 8:48:29 :: Testing SSH credentials for: root Error: The negotiation of encryption algorithm is failed

Might do the trick.

[PMB_CTN]

All success messages, only the last one is with a red X.
The backup is fine but with a warning. Just:
"16.05.2015 13:23:18 :: Failed to create indexer. Details: Guest credentials for the VM are not specified. "

But i think its fine.
Just want to share it

I'm having the exact same issue on B&R v8 when trying to index VCSA 6.0.0.0

[veremin]

Have you raised this issue with our support team already? Thanks.

[PMB_CTN]

Have you raised this issue with our support team already? Thanks.

Yes, that has been done.
CASE ID# 01035477

[neilmacneil]

Hello,

I believe I ran into the same issue before. The same thing happened, it said centos_5 geust unsupported. My issue was that I was using a "Windows Credential" instead of a "Linux Account" when testing.

-Neil

[PMB_CTN]

Hello,

I believe I ran into the same issue before. The same thing happened, it said centos_5 geust unsupported. My issue was that I was using a "Windows Credential" instead of a "Linux Account" when testing.

-Neil

Thanks for the feedback Neil!
What is confusing is the fact that this backup job was not changed and was complating successfully when using the VCSA 5.5, I just upgraded to VCSA 6.0.0 then the "failures" started...
Good idea about the credentials.... My backup job credentials were set to "Windows credentials" BUT when I changed them to "Linux credentials", the indexing still doesn't work, there is a different error message now though...
"The negotiation of encryption algorithm is failed". Not sure if it is safe to apply this fix -> http://www.veeam.com/kb1890 [since it is not specified to be used with B&R 8.X]
Yes SSH and BASH are enabled on the VCSA 6.0.0.0.
When I use PuTTY to logon, using the same credentials, it works just fine.
http://www.thegeekstuff.com/2008/07/how ... ue-on-ssh/
Not sure exactly how B&R 8 is invoking the SSH connection
Same issue here... [Also concerned to try the suggested *unverified* fix]
http://forums.veeam.com/vmware-vsphere- ... 26078.html
Still waiting for feedback from Veeam support on the fix....

[George1421]

I ran this issue to ground with support about a month ago. I've been a bit busy so I wasn't able to update the other thread until now. The KB article above did touch on the issue, but it didn't give specifics of do this and restart that.

To enable the indexing of a vCenter 5.5 appliance I had to do the following:
1) I had to enable the proper ciphers for the sshd service on the vCenter appliance. On the vCenter appliance server edit /etc/ssh/sshd_config search for the line Ciphers aes256-ctr,aes128-ctr and add aes128-cbc make it Ciphers aes256-ctr,aes128-ctr,aes128-cbc Save and exit your editor. Then restart the sshd service. I suspect that centos 5 is failing because it doesn't support the correct ciphers.

You can test the correct function with putty version v0.6 (the specific version is needed). Without the added ciphers line, putty 0.6 will fail to connect to the vCenter 5.5 appliance via ssh. Once you add the ciphers line putty 0.6 will work. FWIW, the current version of putty worked with either setting of the ciphers line.

2) You need to install the mlocate (locate) command. The vCenter appliance 5.5 is based on SLE 11 SP2. After a bit of google-fu I found the needed rpm here: http://download.opensuse.org/repositori ... x86_64.rpm I used wget to pick up the file and rpm to install it. For vCenter 6.0 you will need to get the correct rpm for that OS, which I think is SLE 11 SP4 (but don't quote me).

I do have to say that indexing an appliance adds little value. It is an appliance, in that it should be all or nothing where you would hardly ever do a file level restore. I did want to drive this to conclusion since we have another OpenSuse appliance that is doing the same thing, AND we want to be able to do a file level restore. So the exercise was well worth the time it took.

Once those two steps are complete, indexing worked just like other other centos hosts that worked right out of the box (though I did need to install mlocate on a few of the centos boxes too).