Enterprise Desktop Hidden Gems

View Composer DiskFault: Disk customization failed due to an internal error

There’s a glitch some customers are encountering¬† whereby a Linked Clone desktop is created on vCenter Ok, but is deleted soon after vCenter complains about either “disposable” or “internal” .vmdk files this desktop. Creating and recomposing linked clone desktops fails on VMware Horizon View 6.1.x and all older releases after you have applied an upgrade patch.

On View Administrator, recomposing of pool fails with the error:

This issue occurs when older versions of Horizon View Composer prior to VMware Horizon 6.2 attempt to communicate with VMware ESXi hosts, but SSL v3 is disabled beginning in VMware ESXi 5.5 Update 3b and 6.0 Update 1 hosts.

We’ve created a KB article to address this scenario here: Linked Clone pool creation and recompositon fails with VMware Horizon View 6.1.x and older releases (2133018)

Note: There is a workaround provided in the KB but it is not advised to use it. The workaround makes the VMware ESXi 5.5/ 6.0 hosts vulnerable to security threats reported for SSL v3


0 comments have been added so far

  1. 5.5u3b has been such a nightmare and unfortunately most the blame falls squarely in VMware’s lap.
    When 3b came out we began to evaluate compatibility with two other products we use, SRM and Horizon View.
    We looked at the interoperability matrices that VMware put out. According to them both SRM and View were supported with update 3 (unfortunately the matrices do not elaborate if “update 3” means 3a or 3b ect…). Having been burned in the past we did not take the matrices at face value. Upon browsing the VMware forums there were plenty of posts complaining about 5.5u3b breaking both their SRM and View environments even though the documentation had it listed as compatible. I called VMware support to get more assurance we would be safe to upgrade to 3b. The technicians immediately checked the matrix (as if we hadn’t done so) and said yes its supported. After explaining our concerns based on forum posts he put us on hold. When he came back on the phone he told us to hold off on upgrading because of “issues” reported with SRM and View. VMware appears to have read our forum post in regards to SRM and has now added (as of a few days ago) specific language about SRM compatibility specifically with 5.5u3b. Kudos for that. I then turned my focus to View in which I discovered this blog post. We are planning on going to 6.2 View which according to this article “should” work. However past experience has taught me to to wait. My point of the story is please stop putting out matrices saying things are compatible before you have tested it and proven it. Seasoned VMware admins such as myself know better to wait and see but plenty of others are stuck with a mess because VMware’s documentation (and even tech support sometimes) say things are compatible and then a few weeks later have to recall those statements. It’s troublesome because this is not a new problem for VMware. Admins would must rather see documentation that says to wait rather than have to find out the hard way that VMware hasn’t vetted the process completely yet and put out documentation saying go ahead and upgrade. I understand that VMware has a lot of products that interconnect and testing all those is cumbersome and lengthy but VMware is no small player and they have a requirement to their customers to evaluate all combinations and provide us accurate information from the beginning.

Leave a Reply

Your email address will not be published.