airfrog7 Tracker

Re: vSphere 6.0U3 EAM Error

airfrog7 — Tue, 17 Oct 2017 15:21:39 GMT

We have just had the exact same issue trying to upgrade vSphere 6.0U3 to 6.5. In our case the eam.properties file located at C:\ProgramData\VMware\vCenterServer\cfg\vmware-eam was completely blank. Luckily we had another vSphere server running 6.0U3, so we copied the contents of the eam.properties file from that server and pasted it in to the blank file on the faulty server. There is one URI at the bottom of the file you will need to change to match the hostname of the server. After that the Agent Manager service started OK.

Re: Unable to Delete VMDK File

airfrog7 — Fri, 02 Oct 2015 10:14:20 GMT

Thanks for the replies, and sorry for the delay in updating this thread. I have finally had the chance to go through and reboot every ESXi host which has access to that datastore. However, I am still unable to delete the VMDK file. I have renamed the VMDK file and moved it to a different folder, but was still unable to delete it after this. The VMDK is about 1.5TB in size (which is why I am keen to get rid of it). It was only in place temporarily for testing and was never backed up.

Re: ESXi 5.5 Update 3: Deleting Snapshot Crashes VM: Unexpected signal: 11.

airfrog7 — Wed, 30 Sep 2015 10:36:42 GMT

I have a case raised with VMware about this issue. The tech support guy I spoke to acknowledged this is a pretty major bug. Something is causing the Windows guest (I don't know if it affects Linux) to crash on snapshot removal. They don't have a workaround other than downgrading, which we are currently doing. This issue has apparently been escalated to the highest level as it is affecting an awful lot of customers. They don't have an ETA for when a fix will be available.

The error you see in the vmware.log file for the VM will look something like this:

2015-09-29T17:24:42Z[+8.996]| vcpu-0| I120: SymBacktrace[1] 000003fffbf1af60 rip=00000000162957c5 in function (null) in object /bin/vmx loaded at 000000001611f000

2015-09-29T17:24:42Z[+8.996]| vcpu-0| I120: SymBacktrace[2] 000003fffbf1b460 rip=0000000016377766 in function (null) in object /bin/vmx loaded at 000000001611f000

2015-09-29T17:24:42Z[+8.996]| vcpu-0| I120: SymBacktrace[3] 000003fffbf1b640 rip=00000000003d500f

2015-09-29T17:24:42Z[+8.996]| vcpu-0| I120: Msg_Post: Error

2015-09-29T17:24:42Z[+8.996]| vcpu-0| I120: [msg.log.error.unrecoverable] VMware ESX unrecoverable error: (vcpu-0)

2015-09-29T17:24:42Z[+8.996]| vcpu-0| I120+ Unexpected signal: 11.

In our case it affecting maybe 1% of our VMs every evening, but different VMs each time.

Unable to Delete VMDK File

airfrog7 — Thu, 27 Aug 2015 11:19:02 GMT

I recently deleted a VM with a large (1.4TB) VMDK file attached. When I checked the datastore a few weeks later a there was still a "vmname-flat.vmdk" file left over. However when I tried to delete it via the vSphere client I got an error saying "cannot delete file [DATASTORE_NAME] vmname-flat.vmdk". I connected to an ESXi host in the cluster and tried to delete it from there. Running "rm vmname-flat.vmdk" resulted in the error:

"rm: can't remove 'vmname-flat.vmdk': Bad address"

At the same time the following event was logged in vmkernel.log:

"2015-08-27T11:09:02.904Z cpu7:18223819)Fil3: 8848: Truncating <FD c157 r32> failed: Invalid address"

I have tried from a few different ESXi hosts, all with the same result. running lsof shows that the file is not locked by any process.

How can I delete this file?

Re: ThinApp Packages not Detected by Workspace

airfrog7 — Thu, 08 Jan 2015 15:55:17 GMT

Thanks very much! That fixed it!

I was starting to tear my hair out over that one. All I had to do was stick the ThinApps in subfolders.

Thanks again!

ThinApp Packages not Detected by Workspace

airfrog7 — Thu, 08 Jan 2015 10:02:26 GMT

I have a VMware Horizon View 6 Proof of Concept environment. I have configured ThinApp within View and added some packaged apps. I have assigned these ThinApps to a desktop pool and they are successfully pushed out to the virtual desktops when users login. So from that point of view I am happy the ThinApps are working OK.

However, I have just installed Workspace 2.1 and it is not detecting the ThinApp packages. I have enabled View Pools within Workspace and it detects my desktop pools OK. I have also enabled ThinApp packaged applications and pointed it at my ThinApp file share. However, every time I try and manually sync (or the automatic sync runs) from within Workspace I get the following error:

Push is scheduled to take place:

Every day at 11:55 pm

Error occurred in Packaged applications (ThinApp) sync. Please check if Packaged applications (ThinApp) configuration is correct and the share path is reachable.

The /var/log/messages log on the virtual appliance contains this:

2015-01-08T09:54:14+00:00 XXXXXwork01 ThinAppRepoService: t@349c7700: Starting import cycle from share (\\XXXXXview01.viewtest.internal\ThinApp\).

2015-01-08T09:54:14+00:00 XXXXXwork01 ThinAppRepoService: t@349c7700: Mount path [\\XXXXXview01.viewtest.internal\ThinApp\] is CIFS, acquiring credentials.

2015-01-08T09:54:14+00:00 XXXXXwork01 ThinAppRepoService: t@349c7700: Initializing application share discovery

2015-01-08T09:54:14+00:00 XXXXXwork01 ThinAppRepoService: t@349c7700: Initialization of Application share discovery was successful

2015-01-08T09:54:14+00:00 XXXXXwork01 ThinAppRepoService: t@349c7700: Ending import cycle (0 app scanned, 0 app processed).

So Workspace is successfully connecting to the Share but cannot detect any of the ThinApp packages. I have tried rebuilding one of the ThinApp packages with the "Manage with VMware Workspace" option ticked, but the package still isn't detected. The permissions on the file share and the packages look correct.

What do I need to do to get Workspace to detect the ThinApp packages?

Re: Unable to log in to Orchestrator Client using SSO

airfrog7 — Fri, 04 Apr 2014 14:08:08 GMT

This issue is now resolved. I added our AD identity source to the list of Default Domains via the vSphere web client in "Administration - Sign-On and Discovery - Configuration". I then restarted the vCO Configuration server and vCO Server in teh Orchestrator Configuration web console in "Startup Options". I was then able to log in via the Orchestrator client.

Re: Unable to log in to Orchestrator Client using SSO

airfrog7 — Wed, 19 Mar 2014 12:54:46 GMT

Thanks for the quick reply. When I successfully authenticate on the Test Login page, both user@domain.tld and user@domain work (domain\user doesn't). From the client, user@domain and domain\user both produce "unknown user" errors in the log:

ERROR [VcoFactoryFacade] Unable to login (Ex: javax.security.auth.login.LoginException: Cannot login user : domain\user, user unknown)

Unable to log in to Orchestrator Client using SSO

airfrog7 — Wed, 19 Mar 2014 12:42:45 GMT

I have installed vCenter Orchestrator 5.1.1 and have successfully registered it with SSO. If I try logging in via the "Test Login" tab on the vCO Configuration web site I get a message saying "User logged in successfully". However, if I try and log in as the same user via the Orchestrator Client (on the Orchestrator server itself or a separate PC) I am unable to log in. I get a message in the client saying "Invalid username/password". In the Orchestrator log I get an error saying:

ERROR [VcoFactoryFacade] Unable to login (Ex: javax.security.auth.login.LoginException: Unable to login (reason : ch.dunes.login.ldap.LdapElementGeneric cannot be cast to ch.dunes.login.ldap.LdapUser))

I have tried logging in as various different user and admin accounts, but they all get the same error.

Does anyone have any idea what this error means and how I can fix it?