About 3 months ago VMware released AppVolumes 3.0. The 3.0 version is the first AppVolumes release which comes as a virtual appliance with it’s own embedded database and combines app volumes features with UEM features.
I like the fact that VMware is moving towards appliance based models and the combination of AppVolumes features with UEM features is also a logical and smart move.
All good news so far, but when I started testing with AppVolumes 3.0, I was actually really disappointed:
- The AppVolumes documentation is missing a lot of information
- It is not possible to migrate appstacks from AppVolumes 2.x to 3.0. So you have to create all your appstacks again from scratch
- One of the major new features, the combination AppVolumes and UEM features (it is called customisations in AppVolumes 3.0) is in tech preview.
- VMware announced different editions of AppVolumes. However there is no possibility to set a license file/key, so how does Appvolumes distinguish between its different versions.
- AppVolumes 3.0 uses Ubuntu version 14.04 as the Linux distribution.
- Why is the appliance Ubuntu based? I am not against Ubuntu, but all other VMware appliances are SLES-based. When automating environments, it is more difficult as scripts used for SLES are different then scripts used for SLES
- Ubuntu 14.04 is not a supported version for vRealize Operatons. This causes issues with vReailize Operations Endpoint agent as the agent is not officially supported for Ubuntu 14.04 and is therefore unstable.
- Assigning a writable volume requires also assigning an appstack. I do not see why this should be necessary.
- It is not documented, what the possibilities are for multiple AppVolume Servers (for scale-out an/or high availability)
- It is not documented, what the possibilities are for using an external database
- In my experience AppVolumes 3.0 was unstable
- The AppVolumes 3.0 Agent crashed a few times during my tests
- The AppVolumes 3.0 Agent startup is extremely slow
- I did not find a way how to delete an old Appstack
- Attaching an Appstack is extremely slow
- I experienced longer logon times In version 3.0 then in version 2.10
If you read twitter messages from people working with and deploying (not selling) Appvolumes 3.0, you will see that I am not the only one that has problems with AppVolumes version 3.0
So, I decided to ask Harry Labana (VP Products, End User Computing at VMware) when a new version of Appvolumes was foreseen
To my surprise within 5 minutes, I received a private message via twitter from Harry Labana where he offered to talk live on the subject. This shows the commitment that VMware has towards their customers and also shows that they actually listen to us.
So, a conference call was setup with Harry Labana and Yuvraj Mehta (Product Manager AppVolumes at VMware) where they took the time to explain me the strategy of VMware Appvolumes going forward. I was however asked not to share the information, so I am not in a position to share all the details. If you want to know more details, I suggest you take contact with Harry Labana.
ON 16 JUN 2016 owever, AppVolumes 2.11 was officially announced with support for Instant Clones. When you read through the article there is a small section at the bottom that explains a bit more about VMware’s strategy going forward with AppVolumes.
My understanding of the above mentioned section is:
- Version 3.x
- aimed towards Horizon Air deployments
- do not use for on-premises deployments
- AppVolumes 3.x will continue to be developed
- Version 2.x
- aimed towards on-premises deployments
- AppVolumes 2.x will continue to be developed.
- Version y.y
- future to-be developed version, bringing Appvolumes 2.x and 3.x together
- aimed towards both Horizon Air and on-premises deployments
My personal conclusion of all this information and from my previous experiences with the AppVolumes deployments I did:
- Do not upgrade/start with version 3.x. Stay with version 2.x for on-premises deployments
- Do not use version 2.x in multi-domain environments ==> wait for an Appvolumes version that will address this
- Do not use version 2,x in multi AD-site environments ==> wait for an Appvolumes version that will address this
- Do not try to package Office 2016 in version 2.x ==> wait for an Appvolumes version that will address this
- Do not use writable volumes in combination with Windows 10 ==> wait for an Appvolumes version that will address this
- Do not use AppVolumes when there is a very stringent requirement on fast logon times ==> wait for an Appvolumes version that will address logon time issues
- Set the expectations right at the customers you work with. Be patient, the product has a lot of potential.
VMware will get there with AppVolumes, we just have to be a little bit more patient. Rome wasn’t built in a day either.