Break the Hardware Upgrade Cycle with Win4Lin Windows Virtual Desktop Server

The current version of Win4Lin VDS is 3.0, but 3.5 is in tail-end beta and probably will be released before this article goes to print. Because it doesn't make a whole lot of sense to write an article about a potentially moving target, we use the 3.0 stable version.

Win4Lin Pro and VDS are the same binary, but different licenses unlock different functionality. There are DEB and RPM packages for 32- and 64-bit Linux. The installation prompts for a license code, and that's when the product turns into either Pro or VDS.

There is no upgrade path from Win4Lin Pro to Win4Lin VDS, so if you have Pro installed, you'll have to relicense it with a VDS license by using the ask_license.sh script.

VDS clients are available for Linux, Solaris and Windows, but the source also is available for download, which allows moderately skilled Linux users to compile a client for almost any platform.

We downloaded our packages from the Win4Lin FTP site (ftp.win4lin.com/pub/releases/linux/pro/3.0/index.html). There are server packages available as 32- and 64-bit RPM, 32- and 64-bit DEB and tarball.

We downloaded the 32-bit RPM package for our test platform, a Centrino Duo Core running at 1.83GHz with 1GB of RAM running a beta of Edgy Eft. We ended up moving to SUSE 10.1 after the initial install, because Edgy's “edgy” kernel had issues with the Win4Lin client. Serves us right for trying to use a beta release on our testing platform, and we've been properly chastened. I mention it only because some sharp-eyed readers may be able to detect differing platforms in some of the screenshots.

The win4linpro_6.3.0-07_i386.deb package was only 3.7MB and installed without a hitch. The VDS installation manual advises that the toolchain for supported distros must be installed prior to installing VDS. The reasoning behind this is that all Win4Lin products provide a specialized KQEMU module in order to deliver satisfactory speed performance. As long as you've dutifully installed the toolchain, the building and insertion of said module will be largely transparent to you (Figure 1).

Figure 1. Building and Installing the Modules

Now it's time to install my single Windows instance. We used Windows XP Home, installed it and allowed it to upgrade itself to service pack 2 before provisioning accounts. To do so, we put our Windows XP CD into the drive and ran the command:

sudo loadwinproCD

If you haven't installed your VDS license yet, you will be prompted to do so at this time. You can choose not to enter a license at this time and use the product for 14 days, but none of the server functionality will be enabled, effectively leaving you with a single-user workstation.

In Figure 1, you will see that we had to use the -r switch to load the guest media. This is because our testing bench already had Win4Lin Pro installed on it previously, and the loadwinproCD command detected this. The -r switch simply tells VDS to reload the guest media.

There are two steps to installing VDS. First, the superuser must copy the guest media to the hard disk, which is what loadwinproCD does. The next step is actually to install Windows, which is done under a normally privileged user account. The process of installing Windows and creating the master profile, from which all other user accounts will derive their Windows environment, are tightly coupled—so much so, in fact, the entire next section is devoted to understanding the process.

Win4Lin VDS uses profile-based provisioning. In a nutshell, this means that a single master profile must be configured. This is the profile all other users will inherit from, and this is also the only profile where patches, upgrades and applications need be installed and other maintenances need be performed. Once a master profile has been configured as desired, individual user profiles are created for each system user.

VDS must be installed under a user account. As with all infrastructure decisions, a few moments spent now can save countless headaches later. I've decided to install my master profile under my main user account jdw. I've further decided that I'm going to provision two other user accounts on my system named jwatson and dwatson. My first step, then, is to create the two jwatson and dwatson accounts. Organizations already running a Linux system quite likely have all of their user accounts set up and may be required to create only an account for the master VDS profile.

To create the master profile, first I log in to my system and run:

sudo adduser jwatson
sudo adduser dwatson

After assigning these new user account passwords, they are ready to go. Now it's time to create the master profile. This involves installing Windows, designating that installation as the master and then configuring it as required.

So, I log out and back in as my master profile user jdw, and then run the installwinpro command.

Various options to this command dictate the characteristics of the virtual machine into which Windows will be installed. I accept the defaults, which include a 4GB disk image size. Depending on the amount of applications you intend to install, 4GB may not be enough. There is no need to take user space into account, however, because individual user's documents and settings are stored in the Linux filesystem on a user's respective workstation and not within the image (Figure 2).

Figure 2. User documents and folders are stored on the Linux filesystem.

The default profile name will be winpro unless you change it with the -d switch. Keep in mind that if you switch the configuration name, you will need that information to export the master profile in the next step.

Take my word for this—back up your image now. Living through one Windows install is painful enough, you don't want to have to do it twice.

Backing up your image is as simple as copying the GUEST.IMG file to another location. If you took the default installation options, you'll find the GUEST.IMG file in /home/jdw/winpro/ (obviously, you'll need to substitute your own user name). If you modified your installation, you'll know where to find it.

Once installation is complete, designate this installation as the master by running the command /opt/win4linpro/bin/export-profile <configuration name>.

If you changed the configuration name while installing the guest session in the previous step, you need to provide that name in place of <configuration name>. If you didn't specify a configuration name, the default winpro was used, and you need not supply it to export the master profile.

Launch the image and customize it. It is critical that you launch and shut down the image at least once in order to create the master profile properly. To launch the master Windows profile, either double-click the Win4Lin icon on your desktop, or run the command winpro from the command line.