App Volumes, a result of VMware’s recent acquisition of CloudVolumes, provides an alternative, just-in-time method for integrating and delivering applications to virtualized desktop and Remote Desktop Services (RDS)-based computing environments. With this real-time application delivery system, applications are delivered by attaching virtual disks (VMDK’s) to the virtual machine without modifying the VM or applications themselves. Applications can be scaled out with superior performance, at lower costs, and without compromising end-user experience.
For this blog post, I have colluded with Justin Venezia – one of my good friends and former colleague working over at F5. Justin and I will discuss ways to build resiliency and scalability within the App Volumes architecture using F5’s Local Traffic Manager (LTM).
App Volumes Nitty-Gritty
For the full blog please see my blog on VMware .com http://blogs.vmware.com/consulting/2015/02/vmware-appvolumes-f5.html
Over the last few years working with VMware Horizon View and doing many upgrades, one of the biggest issues I would hear from customers when planning for an upgrade was, Why do we have to have so much downtime and why with 7 connection brokers do we have to take all 7 down at once.
These questions and issues came up when I was speaking to Engineering about the upgrade process and making it smoother for the customer.
I was told that this in fact was not the case and you did not have to take all connection brokers down during the upgrade process and you could simply upgrade 1 connection broker at a time while the other servers were happily running.
For the full blog please see my blog on VMware.com http://blogs.vmware.com/consulting/2015/02/upgrading-vmware-horizon-view-zero-downtime.html
In this blog post I will show you how easy it is to create a VMware App Volumes AppStack and how that AppStack can then be easily deployed to one or hundreds of users.
When configuring App Volumes with VMware Horizon View an App Volumes AppStack is a read only VMDK file that is added to users virtual machine and then the App Volumes Agent merges the 2 or more VMDK files so that the windows operating system see them as just 1 drive. This way the applications look to the Windows OS as if they are natively installed and not on a separate disk.
To create an App Volumes AppStack follow these simple steps.
- Log in to the App Volumes Manager Web interface
- Click Volumes
For the full blog please see my post on VMware.com http://blogs.vmware.com/consulting/2014/12/app-volumes-appstack-creation.html
With the release of VMware App Volumes I wanted to take the time to explain the differences between AppStacks and Writable Volumes and how the two will need to be design as you start to deploy App Volumes
With App Volumes the way that you manage your Windows desktops is changing and App Volumes will help manage these changes. The graphic below shows the traditional way of managing a Windows Desktop and the way to manage a desktop with App Volumes and the introduction of “Just in Time Apps”
So what are the differences between AppStacks and Writable volumes?
For the full blog please see my post on VMware.com http://blogs.vmware.com/consulting/2014/12/app-volumes-appstacks-vs-writable-volumes.html
With the release of VMware Horizon View has come the ability to not only configure virtual desktops but also virtual applications hosted on Windows RDS servers.
In this post, I will cover a couple of things that you should take in to consideration when configuring virtual applications and how they might affect the sizing of your View Cluster and the number of connection servers you will need.
There many different papers and posts on how to configure RDS servers themselves, so I will not be touching on that in this post. I want to discuss the effects of how the PCoIP connections connect to RDS servers and what you should look out for.
For the full blog please see my post on VMware.com http://blogs.vmware.com/consulting/2014/06/horizon-view-rds-pcoip-design-tips.html