In this guide, we will not spend a long time discussing the different components that make up QVD in great detail, however it is important to understand the basic architecture and how each of the components interacts so that you are aware of what needs to be installed and configured in order to get your QVD environment up and running.

QVD 3.5.0 is composed of several parts:

These components can be installed on the same system for testing and evaluation. Naturally, if you are installing all components on the same system, you will not need to make use of shared storage, however in a production environment you would usually make this available over some network file system like NFS, OCFS2 or GFS2.

For production use we recommend using separate machines for the database, administration tools, and QVD servers. In order to reduce the complexity of your host networking requirements, we certainly recommend that when testing and evaluating QVD, you run the client from a separate workstation. This will also help you to see QVD functioning in the way that it is supposed to work.

The QVD server side components should usually be run on independent systems to ensure that they have adequate resources to run, and hardware requirements will vary depending on the number of users that you wish to service, the number of different Operating System Disk Images that you intend to make use of and various other factors.

For the sake of this guide, which assumes that you are evaluating QVD and will only install a single image and set up a one or two users at most, we recommend the following system hardware requirements as a guideline:

System Processor: 64-bit processor, preferably multi-core. You can support around 8 users per core. 32-bit packages are available for testing but the 4GB RAM limitation for non-PAE modes of x86 processors means that only a limited amount of clients will be possible, and it is certainly not viable for a production environment.

System Memory: At least 2GB RAM. This should be sufficient for up to 4 users.

Disk Space: At least 4GB disk space should be available to contain your operating system image etc. More than likely, you should try to double this to work comfortably with the tools involved in importing an image.

Network Interface: You will need at least one network interface available. A 10/100 Ethernet NIC should be perfectly sufficient. We have succeeded in serving desktops over Wireless connections as well.

You may use any supported client system to run the QVD Client software. At present we support Linux and Microsoft Windows, with beta clients for Android, OS X, and iOS under ongoing development.

QVD Server Nodes make use of a network bridge and virtual network interfaces to facilitate networking across each of the virtual machines that run on the node. In order to automatically provision IP addresses to virtual machines, QVD also runs a DHCP server that will allocate IP addresses within the virtual network range to virtual hosts as they boot up. It is therefore extremely important that you choose a network range that is unlikely to conflict with any of your other existing infrastructure for this purpose. Services running on systems in the same IP network may be affected by QVD or any of the virtual machines that run within QVD.

Networking steps are covered in more detail later in this document, however the most important thing to be aware of at this point is that you should ensure that you have a dedicated network IP range that can be used for the virtual machines that will run within the QVD environment.

Furthermore, in a mononode installation, such as the one that we are describing here, you will need to configure some form of NAT in order for the virtual machines to have network access. This is usually achieved by configuring some _iptables rules on the host. In this document, we provide an example, but you may find that an alternative approach is more suited to your environment.

The preferred way to install the central database is with the package perl-qvd-admin. To install run as root:

After installing perl-qvd-admin you have to perform various manual steps. They are

Because QVD is designed to run from one or more node server the perl-qvd-db package does not require the postgresql server as a dependency. For the purposes of this installation guide, however, we will need the server installed on the local machine. Of course, you could of course use a server on another machine and adapt your config accordingly. Install that as follows for Ubuntu:

And for SLES:

Now, start the postgresql server:

You will need to create a user account and database in postgres, so su to the postgres account (use sudo if not root):

If you wish to use an existing user account you can skip this step.

Once you have access to the database, you can create user accounts with the createuser command. It will prompt for a password for the new user and ask some details on the user account. You can answer n to all.

For example, to create a user called qvd you would use the following command.

The new user can now be assigned as the owner of a database. First we need to create the QVD database.

Use the createdb command to create a database for QVD. Use the -O switch to set the database’s owner to the account you wish to use. In this case we will set the owner to the new user that we created in the previous step.

In a production environment where multiple systems interact with the QVD Database, QVD uses transactions extensively, and requires a higher level of transaction isolation than is configured by default. Furthermore, you would generally want PostgreSQL to be accessible to other hosts on your network. While this step is optional in the standalone solution that we are creating in this guide, you might want to configure these settings to ensure that your system is ready to handle additional QVD Server Nodes. To do this you must edit the PostgreSQL configuration file postgresql.conf. We will assume you are using PostgreSQL 9.3, you may need to adjust some paths as necessary.

On Ubuntu configuration files are located in /etc/postgresql/9.3/main.

On SLES configuration files are located in /var/lib/pgsql/data

The transaction isolation level is controlled with the default_transaction_isolation setting. To enable network access to PostgreSQL in general, change the listen_addresses setting from localhost to *.

For Ubuntu:

And for SLES:

To enable network access for the user qvd, locate the file pg_hba.conf. For Ubuntu this will be in /etc/postgresql/$VERSION/main and for SLES, /var/lib/pgsql/data. Edit this file and add the following line:

host qvddb qvd 192.168.0.0/24 md5

Restart PostgreSQL for the changes to take effect.

Each QVD node uses a configuration file /etc/qvd/node.conf from where it gets, amongst other settings that we will cover later, the database credentials and host name. Once you have finished setting up postgresql, you will need to create this node configuration file. You should have perl-qvd-config-core installed at this point as a dependency, which contains a sample node.conf file. Make the qvd folder in /etc, and copy this template configuration there:

Obviously the permissions on this file need to be as restrictive as possible. The root user and the apache user will both need read access. For Ubuntu, the default apache user is www-data, so let’s change the ownership:

For SLES, replace www-data with wwwrun as that is the default apache user.

Now, make the file unreadable by anyone outside of the owner and group:

Now you will need to edit the file /etc/qvd/node.conf to include the details needed to access the database. Your configuration file should look like this:

First, the nodename entry and the database.host entry should match your machine’s hostname, so the example above does need some editing.

The database host should also match the hostname or IP address for the system where your database is located. By default the database name is usually set to qvddb but for customized installs, this may be different. You will also need to set the database username and password, which you configured when you set up the database.

Finally, you may optionally add a log level for troubleshooting purposes.

It is now time to populate the database with the tables that will be used to hold data for QVD. Before we can use any of the QVD tools, we will need to configure the database, user name and password in the QVD configuration files.

Once done, execute qvd-deploy-db.pl. It creates the table structure that QVD needs.

Login to postgresql and issue the following command to list the tables used by QVD:

It is now time to install the QVD Server. To do this, ensure that you have root privileges:

for Ubuntu, and for SLES (where the packages are separated out):

This will install all of the QVD server utilities, as well as all of the dependencies required to run a QVD Node.

It is also worthwhile installing the QVD CLI Administration utility at this point to help with some of the steps that you will perform during this phase of the setup process. The QVD CLI Administration utility is included in the perl-qvd-admin package, so more than likely you will already have it installed. Nonetheless, it is possible that you have decided to install the different components on different hosts, so for the sake of completeness, you can install this utility as well.

For SLES:

This useful tool permits scripting all the operations that can be performed using the web administration tool in the perl-qvd-admin-web package. You can install it on any host that you want to use to manage your QVD Server. For instance, you may want to integrate QVD with an external monitoring tool such as Nagios, so installing the QVD CLI Administration utility on this host would make this possible.

The QVD Administration utility requires access to the QVD Node configuration file in order to function properly. We will set this up in the next step, but it is worth keeping in mind that if you want to install this utility on any other host, you should copy the QVD Node configuration file to the host where you intend to run the tool.

While it is possible to add other configuration parameters to the QVD Node Configuration file that we edited above, this file is simply used to bootstrap the server and thereafter the server will refer to the database to find any other configuration entries, so it is better practice to set QVD configuration parameters within the database.

There are some parameters that must be defined in order to tell QVD about its environment (for instance, the range of IPs available for the virtual machines or their default gateway). These parameters are mandatory and the QVD daemons will refuse to start unless they are defined. They are as follows:

These entries can be set on the database using the command qa available from the perl-qvd-admin package as follows:

You can also use this tool to set the QVD-WAT username and password:

QVD Server Nodes make use of a network bridge and virtual network interfaces to facilitate networking across each of the virtual machines that run on the node. In order to automatically provision IP addresses to virtual machines, QVD also runs a DHCP server that will allocate IP addresses within the virtual network range to virtual hosts as they boot up. It is therefore extremely important that you choose a network range that is unlikely to conflict with any of your other existing infrastructure for this purpose. Services running on systems in the same IP network may be affected by QVD or any of the virtual machines that run within QVD.

There are a number of configuration steps that may need to be configured manually in order to properly set up the networking for a QVD Server Node. There are often other ways to achieve an appropriate network configuration, so we provide these only as guidelines.

The QVD server needs an x509 certificate and private key for securing network connections. For a production installation you should use a certificate issued by a recognized certificate authority, such as Verisign or Thawte. For testing purposes you can use a self-signed certificate. In this demonstration, we will step through creating a self-signed certificate, and use this within our configuration. If you already have a certificate signed by a third party, you can skip this step and use your signed certificate instead.

Before proceeding with the installation, it should be noted that as of Ubuntu 14.04, one of the dependencies of the WAT (namely, the package libapache2-mod-fastcgi) is no longer distributed among Ubuntu’s main repository. If you’re installing the QVD WAT in Ubuntu 14.04 or later, you should edit the file /etc/apt/sources.list and uncomment the lines referring to the multiverse repository, then issue an apt-get update to make APT aware of the newly available packages.

Install the package with apt-get:

Or using zypper on SLES:

QVD-WAT makes use of the database connection details within the QVD Node configuration file at /etc/qvd/node.conf. Since we are installing all of the components on a single host, the existing file should not need to be edited. However, if you have opted to install each component on a different host, you could copy the configuration file from your QVD Server Node host to the host that you are using to run QVD-WAT.

As of QVD 3.1, the Web Administration Tool uses the Apache web server (as well as bundling a compatible version of libcatalyst-perl, previously a dependency). The packages provide a basic site file /etc/apache2/site-enabled/qvd-wat.conf, which you may wish to have amend if necessary, though that shouldn’t be necessary for most vanilla setups.

You will need to restart apache afterwards if you do make changes:

or

if you are using SLES.

Now you can test the connection in your browser, visiting http://localhost:3000

To login, you can use the default username and password:

After that, you should change the default password using:

Now that you are able to connect to QVD-WAT, you will need to register the QVD Node Server that you have configured as a node within the QVD infrastructure. To do this, you can click on the Nodes link at the top of the page, or go to http://localhost:3000/hosts/.

Click on the New button and you will be presented with a screen that looks like this:

Enter the Name of the host node that you are adding, in this example setup this should match the name of the node that you have set in the node.conf file.

Also enter the IP address of the host that is running your QVD Server. This should be the externally facing IP address that you expect client applications to connect to.

Finally, click on the addhost button to save the information that you have just entered.

If you wish to do this via the command lines, simply type in the following:

Of course, replace with the correct info as needed.

In order for QVD to serve a desktop to a user, you will need to create an OSF (Operating System Flavour) and assign a DI (Disk Image) to it. The OSF allows you to provide different users with different operating systems, or simply to provide different applications or environments to users with different requirements. As already mentioned, the image is loaded into its own virtual machine for each user that connects to the server. This means that you can have one image that is used to serve multiple users. On the other hand, you can install as many images as you require, so that in a worst case scenario you have a different image for each user.

If you click on the Users link in the navigation bar, or go to http://localhost:3000/users/, you are able to add new users to QVD and manage any existing users. At this point, you will have no users listed. It is time to add a new user.

Click on the New button to add a user. You will be presented with the following screen:

Enter a Login name for the user. This should be a standard Linux username, usually in lowercase and with no spaces or reserved characters. For the purpose of this guide, we suggest you enter a username like qvddemo.

Enter a Password for the user. This should be a normal Linux password, although there are no limitations on length. In the spirit of reasonably good security, we recommend that the password is at least 6 characters long and contains uppercase, lowercase and numerical characters. Something like 54ghFe9 would be a sensible choice.

You will need to re-enter the password in the Confirm Password field.

Click on the Submit button to create your user.

Adding users on the command line is just as easy:

There’s an important caveat to this: you shouldn’t create any user whose username matches any one already existing in the disk images. Examples of this are sys, mail, nobody, etc. Attempts to do this will cause permission issues when the user connects to their virtual desktop and the NX session is established, making it impossible to get to the desktop.

Once you have added a user, you will return to the Users screen in the QVD-WAT and you will see your user listed here. The user will have been allocated an ID. If it is your first user, this will more than likely be 1. You will notice that this ID is also a link, and a magnifying glass icon is displayed alongside it.

If you click on the ID link or magnifying glass icon, you will be taken to a new screen where you are able to assign a Virtual Machine to a user, or change the User’s password.

At this point, there are no Virtual Machines set up within QVD. We can add a new Virtual Machine and assign it directly to the current user from this page.

Once you are happy that the hkd is up and running, click on the New Virtual Machine link.

You will arrive at a screen that looks like this:

Here, you only need to provide a name for the Virtual Machine instance, and select the image that should be loaded into the Virtual Machine.

In the Name field, enter a useful name for the Virtual Machine. Usually something like a combination of the Username and the Image name would make sense here. So something like QVDUser-Accounting.

Now simply double click on the Image that you wish to load into this Virtual Machine.

If everything behaves correctly, this should bring you to a page that looks like this:

This page is also accessible by clicking on the Virtual machines link in the navigation bar, or by going to http://localhost:3000/vm/.

From this page, it is possible to see the status and manage any Virtual Machine within QVD. At this point, we want to see QVD in action, so we will not spend any more time discussing the options available here.

Simply check the checkbox next to the listed Virtual Machine and then click on Start. After a minute or two, you should see the Virtual Machine State change through various phases of the boot process. If everything goes well, you should eventually see that the State changes to running.

To add a Virtual Machine on the command line, enter the following:

Make sure you match up the user_id and osf_id values with the user and osf instance you want. If you are unsure of these, you can query the values like this:

Each command will return an id for the user and the osf options respectively that you can use.

From this point, you should be able to connect to QVD using a client and connecting as the user that you have just created.

If you are using Microsoft Windows as your base platform to run the QVD Client application, you will need to download the QVD Client installer manually. You can download the installer from:

http://theqvd.com/downloads/windows/qvd-client-setup-3.5.0-27493.exe

Once you have finished downloading the installer, run it as a normal executable file and follow the wizard through the installation process.

Once you have finished the installation, you can either run the client from the shortcut on your Windows desktop (if you selected to add the shortcut) or from the QVD menu in your Applications menu. This will open the client so that you are ready to connect.

Downloading and Installing the QVD Client

Once you have the GUI client running, you can enter the Username for the user that you created in QVD, the Password that you configured for the user, the Server hostname or IP address for the QVD Server Node that you created, and you can choose the level of compression for the connection by selecting a Connection type.

By default, the Connection type is set to Local. This setting is appropriate for connections over a local area network. There are also options for ADSL, which would be appropriate for any broadband connection, and for Modem which can be used in cases where bandwidth is severely limited or impaired.

Changing the Connection type will increase the compression used to deliver the virtual desktop across your network connection. It also increases the amount of caching that the client performs to limit the amount of screen refreshing that needs to take place.

In general, using heavy compression and caching will still afford your users the ability to work comfortably within their virtual desktops. However the quality of graphical rendering will be slightly inferior.

Once you have completed entering your connection details, simply click on the button labelled Connect and your virtual desktop should load.

In this guide, we took advantage of a pre-built image and simply loaded it into QVD. At this point, you are more than likely asking yourself whether you can create your own images. The answer is a resounding Yes!. We provided an image so that you could get started very quickly to evaluate our product.

The steps to create your own image are relatively easy to follow and are documented fully in the QVD Administration Manual in the chapter titled DI Creation.

An OSF needs to run the QVD Virtual Machine Agent (QVD-VMA). Currently, QVD has packages for Ubuntu and SUSE Linux. However, the QVD-VMA is simply a perl script that can run on any Operating System that supports Perl and that can run an NX Server. This means that you can create an OSF for any Linux distribution or for Solaris.

If you’re happy with the current image, or you have already created your own, you may want to know how you can edit this image to include different applications, or to change behaviors within the image. If you have already tried to do anything like this connected to your virtual desktop using the client application you will have realized that changes within the base operating system image are not persistent. That is, when you restart the image, any changes are lost.

This is actually one of QVD’s strengths. It helps to protect all of your users from damaging changes and ensures that if any desktop is compromised the damage only lasts for as long as the desktop is running.

However, it is possible to change an image and to install new applications. In order to do this, you effectively run the image in a different mode. This will allow you to make changes to the underlying image file, so that when it is reloaded all users who access the same image will see the changes.

The ability to switch modes so that you can edit your OSF is available within the QVD-WAT. The process for editing an image is fully documented in the QVD Administration Manual in the chapter titled Editing a DI.

In some rare cases, the HKD running on the QVD Nodes could terminate leaving some orphan virtual machine process behind (this could happen for instance, if some administrator kills the daemon processes).

In order to stop any orphaned virtual machines as soon as possible (otherwise, they could be started in other node simultaneously, thus corrupting the disk images), the qvd-vm-killer program has to run every minute.

Install the perl-qvd-vmkiller package so the following entry is automatically added to the crontab:

You may already have your own authentication infrastructure in place, particularly if your organization makes heavy use of Microsoft Windows and Active Directory, or if you use some other LDAP service to manage your users. In this guide, users were created within the QVD-WAT and added into the PostgreSQL database. However, it is relatively trivial to point QVD at an LDAP resource to handle the authentication of users.

This is controlled by configuration keys in the QVD database that can be changed using the CLI Administration Tool.

For example, to set up authentication against an LDAP server that runs on the machine aguila on the port 389 with search base dc=example,dc=com you would execute the following command:

When a client attempts to authenticate, the QVD Server Node will connect to the LDAP Host and perform a search for the user with the uid attribute matching the provided username. The LDAP search is performed with a default scope of base. Once a match is found, a typical BIND request is performed for the user and if successful, the user is authenticated.

It is possible to change the default values for the scope and filter used in the LDAP search, to match your environment. For instance, you might do the following using the CLI Administration Tool:

Currently, you still need to add all of your users within the WAT, since you will need to assign the users each to a virtual machine. However, this facility will simply ensure that users are authenticated against your LDAP repository.

It is possible to automate the provisioning of users and virtual machines from LDAP to QVD and there are tools available to do this, but they are not released with the Open Source Edition of the software. Further details are available within the QVD Administration Manual

If a Virtual Machine doesn’t start properly or you need to access it directly as an Administrator, QVD provides a virtual console, SSH access and can even offer VNC access to a virtual machine (VNC option is only available for KVM images).

For situations where a virtual machine doesn’t start, it will more than likely be shut down and will enter a blocked state so that clients are unable to connect to it. An Administrator is able to unblock a virtual machine and restart it. Using telnet, the Administrator can then view the boot process as if at a serial console. If the machine manages to get past the boot phase and networking is loaded correctly, the Administrator can use SSH to access a terminal within the virtual machine.

These topics are fairly advanced and are covered in much more detail within our QVD Administration Manual

This Installation Guide is mainly focused on demonstrating how easily you can provide Virtual Desktops to end users by using the KVM hypervisor within the QVD infrastructure. For environments where the base operating system used for the desktop platform will essentially be the same as the host operating system, you may be able to benefit from improved performance and resource management by taking advantage of LXC technology in conjunction with QVD.

As of QVD 3.1, the KVM hypervisor can be disabled and virtualization can be achieved using Linux Containers (LXC). This is an exciting new OS-level virtualization technology that allows for a greater number of guest VMs by running on the same kernel as the host system, increasing efficiency. LXC setup is slightly more involved and is beyond the scope of this guide, please refer to the chapter on Using LXC Virtualization in QVD in our QVD Administration Manual for further information.