VD2422: Offline VDI
Published on 17 Sep 2008 · Filed in Liveblog · 1115 words (estimated 6 minutes to read)This is VD2422, and the presenter is Chris Leroy from VMware.
I arrived at this session late (about 15 minutes late) after running into a customer in the Solutions Exchange. This session is about offline VDI, which is the ability for users to check out VMs and run them while disconnected from the “traditional” VI environment.
As I came in, the presenter was showing off the check-out process, in which the user uses the VDM Client to check out a VM. As part of that check out process, the VM is copied to the client. Depending upon the size of the VM, this may take some time. VI administrators will also see a variety of tasks that get spawned as a result of checking out a VM, and controls for that VM such as pause, resume, power off, power on, etc., are all disabled while the VM is checked out.
The menus in the VDM Client are context-sensitive; the menus change from “Check Out” to “Check In” depending upon the status of the VM. Other commands may also appear based on the status of the check-in/check-out process itself. For example, there is a “Cancel Check Out” during the process of checking out a VM.
VirtualCenter uses snapshots as a “checkpoint” for the check-out/check-in process. By using snapshots in this way, the check in process is incremental, meaning that only the changed data needs to be transmitted back to the VI environment.
One thing that I didn’t see during the check-in/check-out demos and description was the use of the “fast start” VMDK streaming technology that was discussed last year in San Francisco at VMworld 2007.
Next the presenter showed how to use policy to control access to checking out a VM. For example, an administrator can set a policy that prevents a user from checking in an offline VM; in this instance, the user essentially has to “throw away” changes made while the VM instance was offline.
In addition, the offline VM functionality uses encryption technology—presumably taken from VMware’s ACE product offering—to secure the data while it is outside the VI environment. Even the client-side UI looks exactly like stuff taken from VMware ACE and VMware Player. (This isn’t necessarily a bad thing, by the way; it shows that VMware is leveraging additional products, like they should.)
The presenter was using a variety of video clips to demonstrate the functionality; in the next clip, he showed the VDM Connection Server being shutdown to simulate a user actually being disconnected or away from the corporate network. In this instance, the VDM Client recognizes that it no longer has a connection to VDM and certain actions are disabled as a result.
Getting into the technical details, the offline VM is a full copy of the VM that is encrypted using 128-bit AES encryption. Authentication through VDM Client is required; you can’t run the VM in ACE, Player, or Workstation, and it can only run on the client device to which it was copied.
Access to an offline desktop is controlled via Active Directory and entitlements. VDM includes policies to control offline desktops; these policies include whether or not a VM may even be checked out, how long a VM may remain checked out until it needs to contact the VDM server, whether or not USB devices or printing is allowed, whether a user is allowed to perform a rollback, or whether Single Sign On is permitted.
Regarding VDM authentication (note that VDM authentication is required in order to run the offline desktop), the VDM client creates an offline challenge built on the last successful online authentication. I’m glad the presenter discussed that; I was wondering how that would be handled.
As expected, the VDM client will periodically try to reconnect and update policies.
When authentication occurs offline (using the offline challenge), a full online authentication may be required in order to perform sensitive operations. Authentication using RSA, for example, might be required after an offline authentication once connectivity is re-established.
Offline VDI uses a stripped down version of VMware Player, and requires the full Win32 VDM Client (you can’t use the web interface). On the server side, VMs are locked when they are checked out. VDM also knows how to speak to VI, but APIs had to be extended to allow check-in/check-out and to build logic around how to handle checked-out desktops.
Data is transferred using the same VMware internal protocol that VMware Converter and VI cloning/provisioning uses when data is transferred between the client and a VMware ESX server. Only changed blocks are transferred, although some file system optimizations are used. There is some support for data compression, can be paused or resumed, and can travel inside SSL via the VDM Secure Gateway.
When multiple transfers are in place, the load is balanced across VMware ESX server according to a calculation of “transfer slots”. VMware ESX servers can be configured with how many transfer slots they are given.
The flow of a checkout request:
-
Client sends a checkout request
-
VDM server validates the request (checks the policies, verifies the disk space that the client needs, qualifies the VM configuration)
-
VDM then powers down the VM, takes a snapshot of the VM, enumerates the data that the client needs, and the generates a new VM configuration based on the existing VM on the VI environment
-
The client merges the new offline desktop configuration with any existing configuration
-
The client transfers the data it needs, as determined by the enumeration process earlier
A check-in request is a bit simpler:
-
Enumerate the data in the offline desktop’s disks that need to be transferred back to the server
-
Transfer the data back to the server
-
Remove the lock on the desktop
There are a few limitations. Only Windows XP is supported, and small number of concurrent check-ins and check-outs are supported. There is no support for non-persistent desktop pools, and there is no support for View Composer (Scalable Virtual Image, or SVI).
For future enhancements, VMware is considering the use case when the user primarily works from the client desktop. In this instance, check-in processes are more likely to be background processes that should be initiated automatically. These are essentially considered to be restore points or for alternative access. This use case could extend the reach of VDI quite extensively.
More future work is being spent on integration between offline VDI and View Composer. Finally, consideration is being given to allowing offline VDI to work on platforms other than Windows, such as Mac OS X or Linux (note that earlier it was stated that the Win32 VDM Client is required for offline VDI).
At this point, the presenter closed the session.