We’ve been busy at the QVD with a bunch of new features due in our upcoming release. Last week we talked about QVD Shared Folders which provides your users with instant access to their local files, convenience at a click of the mouse. This week we take a look at Disk Image Aging, a feature aimed more at helping your business and making the lives of your administrators easier.
So what is Disk Image Ageing exactly and how can it help your business? Let’s take an example and say your company deploys the QVD along with a desktop application to your users. The desktops and indeed your application will need to be maintained to keep the software up to date with new releases and security fixes. The image can be updated manually or using a configuration management system such as cfengine. That done, the application could be updated using a script, for example:
# cd /var/lib/qvd/image/default/opt/myapplication
# rsync -avz remoterepository:/stableversion/myapplication/ .
# version=$(awk '$1 ~ /version:/ {print $2}' /etc/myapplicationversion)
# cd /var/lib/qvd/image/default/
# tar cfz /var/lib/qvd/storage/staging/myimagedi-$version-$(date +%Y-%m-%d).tgz .This will create a tgz of your new disk image, complete with the updated application, in your QVD staging folder. To deploy the disk image, simply use the QVD administration tool:
# qa di add path=/var/lib/qvd/storage/staging/myimagedi-9.3-2013-09-23.tgz osf_id=1 version=9.3
This will add your fresh disk image which will be allocated the tag head. Assuming your install is set up to use the image with the default tag and not head, find out the di_id and tag it as default.
# qa di tag di_id=15 tag=default
So far this is pretty simple. However, there are a couple of problematic scenarios that may arise in this situation. The first is that a running VM that is in a disconnected state will of course continue to server the outdated disk image. This is easily solved; once you are sure that the new image has been deployed on each QVD node (we use a helper script for this), your update script can stop these VMs and thus ensure that each new user is served the new image.
The second issue is that of users still running the now outdated disk image and still actually connected. This would imply that the user is in an active session with the QVD desktop and randomly disconnecting them would not be desirable. This is where QVD image ageing comes to the fore. QVD 3.4 will provide a system for ageing disk images, in the form of hard and soft limits that can be set by the administrator to ensure that users are upgraded to the latest disk image in a timely fashion. This is achieved by setting one or both limits when adding or tagging a disk image (each is optional and interdependent of the other). This is achieved using the expire-soft=DATE and expire-hard=DATE options with either the tagging or adding of a new disk image:
# qa di tag di_id=15 tag=default expire-soft=now expire-hard="NEXT SAT"
As you can see, the parameters for the date itself can be pretty user friendly. They follow the same format as the at command in Linux, which allows pretty complex specifications while at the same time being fairly human readable. See the at man page for further info.
The soft limits can be set to trigger a hook or mechanism of the administrator’s choosing to alert the user of the need to log out as soon as is feasible. This hook would also be responsible for ensuring that a VM is restarted when the user disconnects, allowing QVD to serve up the new disk image. The great thing about soft limits is that they are extremely flexible – the hook can be any Linux executable, meaning that the administrator chooses how they want to react the the soft limit being reached.
By contrast, hard limits are a much simpler proposition. For particularly trenchant users who are perhaps indisposed or choose to ignore requests to log out, hard limits provides an option to forcibly restart a VM. This means that the administrator can set a limit to ensure that all users are using the latest disk image with whatever new features and security upgrades are deemed necessary
The pretty much covers the expiration limits coming up in the next version of QVD. They are simple and yet, in the case of the soft limits, as powerful as you need them to be. Next time we’ll take a look at Shared Folders, another fantastic feature that’s in the pipeline which bridges the gap between your local client and the QVD desktop by providing access to your local folders within QVD itself.