Desktop Composer DiskFault: Selected parent VM is not accessible

[Jirv311]

Just upgraded to 4.0.1 on Connection Server and Security server and everything still worked. Thought I would update the agents on the View Golden Image and now during the Recompose process it fails with this error: *Desktop Composer DiskFault: Selected parent VM is

not accessible*. I tried blowing away the Persistent Pool and recreating it and same issue. It very slowly created the "temp" VM and then once that finishes and it tries to configure a VM it fails and deletes itself. I searched for this error and came up with an article that says VMWare support had someone rebuild an ESX host. I hope this is not the case. Any ideas?

[JAnuth]

I'm seeing the exact same thing. New installation. New ESX server, new View Manager, new domain even. The error received is "Unable to create new VM - Desktop Composer DiskFault: Selected parent VM is not accessible"

Waiting on word from support...

[JAnuth]

Just got off the phone with them and have a solution. My esx host had a missing carriage return in /etc/vmware/config. Specifically, this line:

prefvmx.consolidateDeleteNFSLocks = "TRUE"authd.proxy.vpxa-nfc = "vmware-vpxa:vpxa-nfc"

Should appear as:

prefvmx.consolidateDeleteNFSLocks = "TRUE"

authd.proxy.vpxa-nfc = "vmware-vpxa:vpxa-nfc"

Hope this helps...

[Jirv311]

Could you possibly explain how to check this? I'm familiar with Unix/Linux/BSD but not real sure how I'd get there on these hosts. It's really throwing me for a loop right now.

Also, when you were running into this, was it taking an abnormally long time to clone to the temp image, before it eventually failed?

Thanks for the help on this!

[JAnuth]

Yes, it was taking a while followed by a failure.

You'll first need to have an account with which you can ssh onto the esx server. If you don't have such an account already, launch your vSphere Client and point it to the esx server directly. You'll connect as root so you will need to know the root password for this.

Once the vSphere client is up and pointing at the esx server, go to the Users and Groups tab and right click on it to create a new user with remote shell access.

With that in hand, ssh to the esx server, log on, and do a cat /etc/vmware/config to see if this problem is affecting you. If it is, edit the file to include a carriage return. That did it for me. A reboot wasn't even necessary, I just re-provisioned the linked clones and they came up properly.

[trurodh]

I had this very same problem. After working with VMware we came to the conclusion after sending off the log bundles that there was a problem with the ESX host certs. All we had to do was restart the authd service. Just try as follows.

service vmware-vmkauthd restart

This did the trick!

Thanks.

Rod

[mrtharp313]

I was just about to call VMware about this as well and I surmized it came from patching to update2 over the weekend.

So did you restart the authd service on each of your host?

Any background how you came to that? I don't see where that service would cause this issue.

thanks

[trurodh]

HI.

Yea, I would have never thought to restart that service either. The VMware Tech was pouring through the logs and apparently these entries were only found by doing a log bundle as opposed to finding them in a specific log file. He just kept on working the problem, never gave up on it. At least we never could determine which logfile those entries came from.

Here is the snippet that made us look to restarting the service.

SSL: Unknown SSL Error SSL Error: error:14092105:SSL routines:SSL3_GET_SERVER_HELLO:wrong cipher returned SSL: connect failed

We did this on all of our VDI hosts, and it is a non intrusive operation, won't cause you to lose any connectivity at all. I had not yet upgraded to Patch 2 so can not say if your problem is different or not.

Hope this helps.

Rod

[mrtharp313]

Thanks for the reply, I guess I'm now the lucky one.

There was no missing carriage return in /etc/vmware/config

restarting the authd service didn't solve the issue

no mis configurations with HA

VM Tech told me to remove my ESX Hosts from the cluster one at a time and re add them. He says the problem is the communication between vCetner and the hosts. Did that manuever last night and no change.

Just created about 1GB of log files from vCenter/composer and my primary broker and FTP'd it to VMware. They are going throug it now.

At this point, I'm wondering if uninstalling all the update2 patches will help, but not having much luck finding out how to do that.

The VM Tech did suggest that any time an update comes out, to reinstall the agent on the gold image. That of coruse didnt resolve my issue either.

I'll update this thread once we get a resolution. I firmly believe that I'm not the only one with this issue so the more heads on it the better.

[Jirv311]

I know this sounds completely rediculous and very obvious, but try and remove and reinstall View Composer on the VC server. I took all the same steps as mrtharp313 and nothing else worked until I did that. My problem is now resolved.

[mrtharp313]

Wow that sounds scary. Did you uninstall Composter first or did it reinstall/repair over top. Did it affect any of your existing pools or replicas?

I thought about trying that, but the fear of the Composer DB getting jacked up and me having to rebuild everything kept me away from that option.

please share the steps you took.

thanks!

[trurodh]

We did try the uninstalling composer and reinstalling. This did not help, but was a good thing to try. It did not hurt the database at all, just point back to your ODBC connections and it is just fine. The thing that bugs me is that the issue appears to happen due to multiple reasons as opposed to a clear fix. This seems to point to a potential bug that has yet to be identified fully.

Thanks.

Rod

[Jirv311]

I only had 1 pool for testing which was broken after the upgrade anyways so I wasn't concerned about the database. However, it was still fine afterwards. I completely removed Composer and then reinstalled.

I agree it is something other than just 1 fix for this issue. It seems multiple factors play a part in fixing it.

[picou · Accepted solution]

Same here.

We had exactly the same issue, nothing else worked but uninstall / reinstall of composer did it.

Thanks!

[mrtharp313]

That worked for me too. Now my clones need a tools upgrade from the update 2 install. So hopefully that won't break anything further.

I'm keeping my VMware ticket open though so they can find a true fix for this or atleast understand what happened.

thanks to all for their input!

[trurodh]

Did you guys reboot your virtual center servers after you reinstalled Composer? Or did you uninstall and reinstall and it worked without a reboot? If you did reboot, I am wondering if that is actually what fixed us as well. We could not reboot at the time we reinstalled since it was the middle of the day. I rebooted that night and it worked in the morning. Vmware had me try the service authd restart that I mentioned above before I tried to run through the process again. I am now wondering if it was the reinstall and reboot that fixed us as opposed to the Cert (authd) service being restarted. Hmmm.

Thanks!

Rod

[mrtharp313]

Composer uninstalled and did not require a reboot. After re-installing composer, it did require a reboot which I did..

I did reboot vCenter before and it didn't not resolve the issue.

Just heard back from VMware, they are also now reccomending the reinstall of Composer.

[Jirv311]

Exactly the above. On uninstall Composer didn't require a reboot but did after re-install.

[cos14]

We had the same problem, Desktop Composer DiskFault: Selected parent VM is not accessible. I found this article, thought I'd give uninstalling/installing View Composer on the vCentre server and that fixed the problem. Much better than some of the other articles I found that suggested reinstalling the ESX Host!