One of the fundamental concepts behind cloud-based workloads is Mobility & Portability. Mobility & Portability have been continually discussed over the years and we finally see cloud providers offering solutions to import/export workloads from/to their clouds.
Amazon EC2 has a VM Import/Export tool that allow administrator to import VMDK, VHD or RAW file via the ec2-import-instance API. They also offer the Amazon EC2 VM Import Connector for VMware vCenter. VMware has also published a guide of how to convert Amazon EC2 Windows Instances to VMware Workstation or VMware vSphere Virtual Machines (here).
Does it matter for Desktop-as-a-Service?
I am building this discussion on top of my previous article DaaS Identity Management, Federation & Multi-Tenancy. Therefore, before moving forward I recommend reading the mentioned article.
In a perfect world, a organization should be able to move virtual desktop workloads to any service provider they want to. This workload migration could be driven by different factors such as pricing, locality, carbon footprint, etc.
The point that I want to make here is that cloud interoperability and workload migration is becoming more important everyday, and despite we do not have yet live-migration tools to move workloads between heterogeneous clouds, the industry is not far from being able to implement such technology. I believe it’s more a business rather than technical decision nowadays.
For cloud-based desktop offerings workload mobility and portability are key aspects. However, they can be implement in different ways if compared to server workloads.
Unfortunately it’s not as simple as it looks on paper. A number of considerations such as user persona, user data, deployed user applications, Single Sign-On, password policies amongst others essential components would have to be carefully considered for this solution to work seamlessly. In addition to that service providers would have be partners and utilize similar architecture model and solution – or have the ability to migrate workloads between them.
Many DaaS solutions provided today have the non-persistency desktop aspect. When non-persistency is enabled the virtual desktop becomes an empty shell for any user to use it. The data and preferences are loaded into the desktop upon login. Applications are presented based on entitlements.
There are key aspects here to be discussed, such as User Installed Applications, but let’s leave that for another moment. Solutions like Mirage Wanova are key enablement tools for this type of scenario where application persistency is paramount.
With non-persistent desktops in use, just like in Enterprise deployments, the only data to be exchanged between Cloud providers is the user data & preferences, along with VPN, Trusts, and identity management metadata. Don’t get to excited’ we do not have a solution for that today.
Let me exemplify Mobility and Portability with a scenario – If a user tries to access a virtual desktop in a different service provider than his/her default virtual desktop is hosted the service provider will not be able to authenticate the user because there is no pre-configured identity management solution.
In this scenario the service provider also will not be able to authenticate with the customer organization for resource access. This is because the key components such as virtual private network, trusts, links etc. have not been setup between service provider and organization. There is no news here – no configuration, no access.
In order for that work today, the organization and the service provider would need to have all the elements pre-configured before users are allowed to use the service. In theory this process should be completely invisible to users or administrator and it ties back to the Multi-Tenant Identity Management I presented in my previous article DaaS Identity Management, Federation & Multi-Tenancy.
If non-persistency is a feasible use case for the organization, than Mobility and Portability is about user data, preferences and connection metadata. Optimistically speaking, if there was a mechanism to securely federate and share all that metadata we would be much closer to accomplish live desktop workload migration between clouds.