The following options are available to change the paths that QVD uses to look for applications, certificates and other specific data of QVD.

The above values are those set by default.

The following options can be used to change the path to the log file and to control the output of the logging level.

The values above are the default values.

These options must be configured in the QVD configuration file /etc/qvd/node.conf because the logging system is started before the connection to the database. If these values are established in the database, they will be ignored.

QVD generates its log through Log::Log4perl, a standard perl module that offers many possibilities regarding methods of logging. You can choose to send the output to syslog, to a file or even to a database. To send the log to syslog, the following configuration settings can be established in node.conf:

To obtain a complete breakdown of the different logging options available in Log4perl, consult the documentation found at: log4perl.

If you choose to save your logs in a file, make sure to use a suitable method of handling growing log file size.

You can specify the following additional options to control the L7R:

The values that appear above are those set by default.

You can specify the following additional options to control the HKD:

The value set in the example above is the predetermined value. * * hkd.vm.starting.max *: the maximum number of virtual machines that the HKD will allow concurrently in "starting" mode before launching a new instance in a server node.

There are some options that be configured to control the behaviour of the virtual machine inside QVD:

Take into account the if you use the CLI Legacy administration utility you may also need these parameters:

The values shown above are the values set by default.

Be aware that the configuration of vm.network is generally required for the QVD nodes to work correctly.

You will need to create a user inside PostgreSQL to access the QVD database, and you will need to create the real database where QVD can configure its tables and store its data. To do this, you will need to use the sudo command to switch to the postgres account:

As a postgres user, you can create PostgreSQL user accounts with the command createuser. It will ask for a password for the new user and some details about the user’s account. In general, you can answer n to all the options that appear. For example, to create a user called qvd, we would use the following command.

The new user can be now assigned as owner of a database. To create a database for QVD and assign the owner, use the command createdb. Use the parameter -O to establish the owner of the database to the account that you want to use. In this case, we establish the owner for the new user that we created in the previous step.

With the objective of allowing concurrent access from all the nodes of the QVD farm and manage the transactions in a coherent way, the transaction isolation level must be changed from read committed to serializable. This is a very important step that must not be omitted or its database could become incoherent and QVD may stop working.

It is also necessary to allow the database to have network access. By default, it is configured to only listen to the queries in localhost. This must be changed to listen in all the interfaces.

To do this, you must edit the PostgreSQL configuration filespostgresql.conf y pg_hba.conf. In Ubuntu they are found in /etc/postgresql/9.2/main. In SUSE , you will find these files in /var/lib/pgsql/data.

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

To enable network access for the qvd user, add the following line to pg_hba.conf (with the following format: host database user CIDR-address auth-method [auth-options]).

Restart PostgreSQL for all the changes to take effect.

For Ubuntu:

and for SLES:

QVD uses dnsmasq as a DHCP and DNS server for the virtual machines that are executed in a node. To work correctly, dnsmasq needs to be executed by the HKD process.

Firstly, check that dnsmasq is installed. In Ubuntu, execute the following commands and check the status:

In SUSE:

If it is not installed, do it now using your package manager, whether apt-get install dnsmasq, or zypper install dnsmasq.

By default, the Ubuntu package starts the process that is executed as a daemon in the background, so you should avoid it starting automatically. This is done with the following commands in Ubuntu:

In SLES, dnsmasq is managed under the command chkconfig and it is disabled by default, so you should not need to do anything. However, should dnsmasq have been enabled or simply to make sure, you can check that it is disabled executing the following command as root:

IP Forwarding is necessary to route the clients to the correct location. You can habilitate it quickly by executing the following command.

Unfortunately, on restarting the host system, this change will be lost. To make it permanent, you can edit /etc/sysctl.conf and uncomment the line:

You can force sysctl to reload its configuration after having edited this file executing:

There are several ways to configure the network bridge and the appropriate routing to make sure that a QVD client is routed to the correct virtual machine.

The easiest method is to configure the static network interface and a set of iptables routing rules to perform the necessary NAT to translate the IP addresses between its real and virtual network.

To configure its network in Ubuntu, edit the file /etc/network/interfaces and add the following lines:

It is important to point out that in the previous example you will need to change the IP address 192.168.0.2 to the network interface IP address to which you wish its clients to connect. In the example above we use the range 10.3.15.0/24 for the virtual network used by QVD. This range must be unique inside its infrastructure and must only be used by QVD, so the services that start in QVD do not interfere with other systems in the network.

While there are other cleaner approaches to configure its network, these sometimes have problems with specific types of network interfaces,such as WIFI. The approach mentioned above should work for the majority of systems.

Once the network configuration has been written to file, the network bridge interface should become active.

For QVD to correctly manage the configuration of the virtual machine and the subsequent routing, you will need to change some of the configuration settings inside QVD-DB. It is recommended you use the QVD CLI Administration Utility to do this. You can also use the WAT if you have already configured it.

These settings are used to provide a dedicated network environment for the Virtual Machines. You must use IP addresses and network ranges that do not conflict with its existing network infrastructure. In the following example the range 10.3.15.0/24 is used for the virtual network used by QVD.

These settings are described in more detail in the section of the QVD Administration manual titled Virtual Machine Options in the chapter Basic configuration of QVD.

This can quickly be done like this:

QVD has a wide range of very specific configuration settings that control various components inside the infrastructure. We discuss some of them here.

To change a QVD configuration parameter of via the QVD CLIadministration utility, you can do the following:

It is also possible to obtain all the configuration settings of the database and list them:

Lastly, it is possible to return a configuration to its original value:

It is common to use the QVD CLI administration utility to add new QVD server nodes to the QVD database. This can be done quickly from the command line with the following instruction:

The elimination of a QVD server node is equally simple:

You can easily add an OSF to QVD using the QVD CLI administration utility:

There is only one compulsory value to add an OSF, which is name. If the other parameters are left unspecified, theirdefault values are used instead. These are:

You can obtain a list of currently available OSF doing the following:

Using the QVD CLI administration utility, you can attach a disk image (DI) to any existing OSF within the system. This process can take quite some time, since in addition to updating the database, the real disk image file is copied in the directory storage/images inside the shared storage.

On attaching a DI to a particular OSF, we keep the real disk separate from the image that will be served to the final users. This means that you can make changes in the disk image and simply update the OSF, so when the user connects again the image is automatically updated without the user experiencing any disruption to the service.

Both disk_image and osf are compulsory to add a DI. When the DI is added, the image specified in the path is copied in the read-only storage area configured to store active DIs (usually /var/lib/qvd/storage/images).

You can obtain a list of currently available images by doing the following:

The DIs can be tagged with arbitrary chains freely. To tag a DI as default, use the command di tag:

You can tag DIs with any chain, not only default or head. This lets you use significant names for the tags, for example "software_bug_fixed", for use inside the field DI Tag of the virtual machines.

Tags are useful, since they let you attach a new version of a disk image to an OSF without affecting anybody that is using the current image or default image for an OSF. This lets you implement a change and migrate specific virtual machines using a different OSF for the new image while you are testing. If the image fails for any reason or it does not meet your requirements, it is easy to go back to the default image and let the users continue working while corrections are made.

In order to tell a virtual machine that it must use a DI with a specific tag, we edit the VM to change its di_tag field. So if for example we have just finished correcting a software error in a DI and we create the tag "software_bug_fixed", we can use this DI in a VM using the following command:

The next time the VM myvm is started, it will use the DI with this tag.

It is common to use the QVD CLI administration utility to quickly add and eliminate users.

You can also list all the users of QVD by means of the list option:

Be aware that, as explained in the Installation guide, it is not advisable to create a user whose username already exists in any disk image.

You can change a user’s password via the QVD CLI Administration utility:

In the example above, we are changing the password for the user of log in guest. You will be asked to provide a new password.

Adding and eliminating virtual machines via the QVD CLI administration utility is easy. You can specify the user and the OSF by ID or by name:

You can easily eliminate a virtual machine using the following command:

The QVD CLI administration utility can be used to start and stop virtual machines. Unless specified with a particular filter, the action will start or stop all the virtual machines. This command is usually executed specifying a filter to identify the real virtual machine that you wish to start or stop. Examples:

The balancing policy determines the node where the VM will start.

Virtual Machines can be marked as "blocked". When they are in this state, the QVD Client application will not be able to connect to the Virtual Machine. This task can be executed by an administrator to carry out an administration task or can take place when the HKD is unable to correctly manage a virtual machine. The following commands can be used to mark a virtual machine as "blocked" or can be used to unblock a virtual machine that has been set in this state.

Check block and unblock the virtual machine in the manual of the WAT to obtain more information on how to configure this state.

QVD includes the option to configure customized properties for a virtual machine that can be set and recovered via the QVD CLI administration utility. This is useful if you need to write your own behaviours or wish to take advantage of the VMA hooks (See the relevant section about this).

The customized properties are often used when you write your own plugins for the L7R, such as the authentication modules or load balancing.

The customized properties are compatible with the configuration parameters: host, user and vm

To add a customized property, you can use the command _propset:

You can obtain the content of all the customized properties that have been set for a configuration parameter using the command:

Finally, you can eliminate a customized property using the command _propdel:

To activate this option, select it in the configuration tab.

When the shared folders are activated for the first time, the main user directory is redirected (%USERPROFILE% for Windows clients and /home/%user% for Linux and Mac OS X).

On activating the option, a list of shared folders is shown. From this screen it is possible to eliminate folders in the list and add others.

The folders will appear in the user’s personal directory in a subfolder called redirect. GNOME and other recent Linux desktops will also show a shortcut icon on the desktop and in the file administrator, depending on the configuration.

You can specify the following additional options to control the client software on a workstation:

The values that appear above are the ones set by default:

The following image shows the settings currently available in the QVD client.

By default, the Qvd client leaves its logs in ~/.qvd/qvd-client.log in Mac OS X and Linux and %APPDATA%\.qvd\qvd-client.log in Windows. You can change the levels of logging to one of ALL, DEBUG, INFO, WARN, ERROR, FATAL, OFF in the configuration file in the following way:

With version 3.2, QVD introduced support for the btrfs filesystem. This differs slightly from the standard LXC configuration extracting each disc image in a read only btrfs subvolume and making a snapshot of the overlay (non persistent data) for each new VM. This is considerably more efficient than extracting the image in a folder due to the capacities of copy in writing of btrfs, offering a significant reduction in the load of the shared storage through the persistent download in the local node. This gain has a price, however, in the sense that this data will be lost if a client is assigned to a new node.

First install the NFS server. For Ubuntu, this can be done as root using the command:

And for SLES:

Add an entry a `/ etc / exports`in this way:

Take into account that this would mean that your NFS server would configure one of the QVD directories inside the route /var/lib/exports. You can choose another more appropriate location if you prefer to have these files in another route. Once you have added your route inside the exportations of NFS Server, you should load the NFS Server again. For Ubuntu (as root):

Similarly for SLES:

From now on, the NFS Server should make the configured route network available.

Each host system that is executing components of QVD will need to be configured to access the NFS shared resource that we have configured in the NFS server. First, create an assembly point in your host systems:

Make sure you have the necessary tools to access an NFS shared resource installed in your host systems. In Ubuntu, you must install nfs-common:

In SLES, install nfs-client:

To be sure that the NFS filesystem is always assembled from boot up, you must add the following line in /etc/fstab:

Take into account that in the previous line, nfsserver is the name of the server that hosts the NFS shared resource. You should substitute this for the IP address or the name of the resolved host by DNS of its NFS Server. Once you have finished editing your fstad, you should be able to mount the NFS resource in the host systems:

Lastly, you should check that the NFS resource is mounted correctly. You can do this executing the command `mount`and themn verifying the output to see that the NFS resource appears:

QVD makes use of unionfs-fusible to manage the assembly points of the union style. This lets QVD mount directories like the personal directory of the user and temporary data typically managed as overlays inside KVM in the LXC in execution. Since the disk image LXC is a read only system, unionfs-fuse facilitates the assembly of storage areas with writing. So, it is essential that the fuse module of the kernel loads at the beginning of the system.

Since the implementation of LXC differs dramatically from KVM, QVD stores all the associated data with each implementation of virtual machine in directories logically different inside the storage location of QVD.

Whilst the "staging" and "images" directories are used commonly with KVM, most of the functional activity takes place outside these directories. When a virtual machine is started for a user, the disk image that will be used in the virtual machine is extracted literary from the tarball stored in the images directory in a subfolder inside the folder basefs.

When the virtual machine is started, the files system that is extracted under the folder basefs is mounted with the personal directory of the user, stored in the folder homefs and the relevant overlays (in overlays) in a directory in execution time inside rootfs. This directory of execution time is used to load the LXC and serve the Virtual Desktop to the final user.

The content, structure and the purpose of the folder is described in more detail below.

Similar to the implementation of KVM of QVD, it is necessary to create a bridge interface in the host of QVD Node. When a virtual machine is started, a virtual network interface is created and it is linked with the bridge interface. For it to work correctly, you will have to configure QVD with the IP range used for the virtual machines. The bridge interface must be configured with an IP address lower than the range used for the virtual machines, but still in the same network.

The QVD containers use cgroups (control groups), a characteristic of the Linux kernel designed to limit the use of resources of the process groups in the system. A system of virtual files is mounted under the directory /sys/fs/cgroup in which several controllers can be configured, known as subsystems. This directory can be changed modifying the configuration path.cgroup in the QVD database, although this should not be necessary.

By default, the subsystems cpu of the container are placed under the directory by default /sys/fs/cgroup/cpu. This behaviour is controlled by the QVD configuration path.cgroup.cpu.lxc which is defined by default as follows:

Again, it should not be necessary to change this in a default installation.

The standard QVD administration tools, like the WAT and the QVD command line administration utility, can be used to load an LXC image in QVD. The important difference here is that the file will take the form of a compressd file with tar-gzip, unlike a qcow2 image. It is absolutely imperative that the environment has been preconfigured for LXC virtualization, or the images will be copied to the incorrect folder and they will not be loaded when a virtual machine is started.

To load a LXC image in QVD from the command line, you should perform the following steps:

Add an OSF to lodge your image file:

Now add your disk image to the OSF

This will take some time, since the image will be copied from the preparation directory in the images directory.

Now add a user to be able to test the image

Finally, create a Virtual Machine for the User and attach the OSF that this Virtual Machine will use in execution time

If your installation of QVD is correctly configured, you will now be able to start the virtual machine and test it.

Starting an LXC virtual machine inside QVD is no different from starting a KVM virtual machine. It can be manually started via the QVD command line administration utility or started automatically through HKD when a client tries to connect to the virtual desktop managed by the virtual machine. For testing purposes, in general it is advisable to start the virtual machine from the command line:

You can supervise the starting process from the WAT listing the status of the virtual machine.

As the virtual machine starts, its status will change. If the virtual machine is started without any problems, you should check that you are able to connect to it via the QVD client and that the virtual desktop is processed. If the virtual machine is not started correctly or you cannot access the virtual desktop, it is possible that you will have to do some debugging.

Since in reality it is possible to access the filesystem of an LXC image in execution directly from the host operating system, it is possible to review the log files and do a great deal of debugging directly from the host where the virtual machine is being executed. It is important to note, however, that it is highly inadvisable to try any writing operation in the filesystem of a container in execution.

When an LXC virtual machine is started, its several components are combined using unionfs and they are mounted in the folder rootfs in the storage area of QVD (generally /var/lib/qvd/storage/rootfs). Inside this space, it is possible to see the status of an instance in execution in real time. This means that you can quickly access the log files and the configuration information from the operating system of the host. This is often the best way to quickly debug the problems inside an instance in execution.

If this is not enough, you can also connect to the instance with ssh through the IP of the same. Obtain the IP of the VM using a command like:

Once you have the IP, you will be able to execute the ssh command to access the virtual machine.

Before trying to configure QVD to authenticate against LDAP or Active Directory, it is recommendable to test your server first to make sure that it has the correct credentials and the distinctive name (DN) for the server. To do this, you will have to have ldap-utils (Ubuntu) or openldap2-client (SLES) installed in your QVD node.

Once this is done, consult your server with the following command for LDAP:

If you use Active Directory, use this command instead:

In any case, modify your consultation to make it coincide with the one of its own server. Check the results of the LDAP consultation to make sure that connection to your LDAP server is possible from your QVD nodes.

The LDAP authentication is configured inside QVD through the configuration in the QVD database. This can be doneusing the QVD CLI administration utility or the WAT.

In the previous example, we have changed the QVD authentication mode to LDAP, establishing the LDAP host to example.com and the port 389. The basedn has also been established where all the users to dc=example,dc=com will be searched. With these basic elements of configuration, QVD will search in the LDAP directory a coinciding user name, and then, it will make a BIND against that user with the credentials supplied by the client. By default, the search is done with scope base`and filter `(uid =% u). Using our example of the previous host, a client with the user name defined as guest would need a correspondent entry `uid=guest,dc=example,dc=com`inside the LDAP server that is executed in the host example.com available in the port 389. You can change the scope and the filter configuration for the search, to let QVD scan other branches and attributes to find a coinciding user:

The previous examples change the default search range for the authentication LDAP to sub and the filter will perform the search to coincide with the users with the uid or the cn the same as the given user’s name.

The Active Directory configuration is similar to the LDAP configuration, but with a little adjustment in the parameter auth.ldap.filter as follows:

Here QVD coincides with the user’s name in sAMAccountName that is the login name for the user of Windows.

Although it is trivial that QVD authenticates the users against LDAP, it still needs to create users coinciding inside its QVD-DB to assign virtual machines for them. The ‘Auto Plugin` discussed in the following section lets you provide users and assign to them a default virtual machine automatically when logging in. The QVD tools that let you change the users’ passwords inside QVD do not update LDAP passwords, since this can affect the functioning of other installations inside its infrastructure. Although these tools will say that they were successful changing the password, it is important to understand that the password that has been changed is the one stored in QVD-DB for the user, and not the password inside the LDAP directory. If you use the LDAP authentication, the logging in process completely ignores the passwords stored in QVD-DB. The changes in password are done through the tools that you generally use to administrate users.

Examples of RACF errors (with their original text): * R004107 The password function failed; not loaded from a program controlled library. * R004108 TDBM backend password API resulted in an internal error. * R004109 The password has expired. * R004110 The userid has been revoked. * R004128 Native authentication password change failed. The new password is not valid or does not meet requirements. * R004111 The password is not correct. * R004112 A bind argument is not valid. * R004118 Entry native user ID (ibm-nativeId,uid) is not defined to the Security Server.

If auth.ldap.userbindpattern is defined, a bind is attempted with this DN substituting %u for the login. If this is successful the user is authenticated and if it does not work we try the following steps:

Automatic plugin of user provisioning _~~_~~_~~_~~_~~_~~_~~_~~_~~ When a different authentication mechanism is used, like the authentication plugin LDAP, a common requirement exists for users that have been authenticated against the provided plugin. The Auto Plugin has been designed to satisfy this requirement. When QVD is configured to authenticate in an external source, like LDAP, there is usually no register for the users who login. If the _{Plugin Auto} is set up, the user register is automatically created. The user registers created in this way are provided with a default virtual machine, as specified in the plugin configuration. To set up the plugin, add "auto" to the list of plugins set up in the L7R configuration:

Take into account that in the previous example, we are using the plugin auto in conjunction with the LDAP authentication plugin. Now you will need to indicate the automatic complement that OSF will use when creating a virtual machine for the user:

In this case, the new users that authenticate with LDAP will obtain a VM with the ID of OSF that we have specified. It is also possible to force the use of a disk image DI Tag. This can be done adjusting the following configuration option:

A typical example to use the LDAP plugin and the auto plugin together would require to execute the following commands:

Tip: use inverted commas between any of the special characters that can be subject to expansion shell or that can be interpreted in an unexpected way, like pipes, brackets, ampersand, etc…

This would mean that as authenticated user for the first time, using QVD they would authenticate using its LDAP repository and would automatically obtain a default desktop to start work immediately.

This load balancer assigns virtual machines to random backend nodes.

The settings of the soft limit are not enabled by default in QVD 4.0. Configuring the VMA and deciding about the action to do when a soft limit is reached is a task for the creator of the image.

Key: vma.on_action.connect

This hook is executed when a user starts (or restarts) a session of X-Windows using the QVD Client. The script will be executed after all the supply hooks have been activated.

They also receive the following parameters by default:

This hook is able to receive other connection parameters and any additional parameter assigned to the VM inside the QVD-DB.

Key: vma.on_action.pre-connect

This hook is executed when a user starts (or restarts) a session of X-Windows using the QVD Client, with the difference that it will activate a script to be executed before any of the supply hooks are implemented.

The parameters for pre-connection are the same as those for connection.

Key: vma.on_action.stop

This hook is executed when a session of X-Windows receives a request to be closed. This behaviour is usually produced when the VMA receives a request of this type from the QVD-WAT or from the QVD CLI administration utility.

There are no additional parameters for this hook.

Key: vma.on_action.suspend

This hook is executed when a session of X-Windows is suspended. This usually occurs if a user closes the QVD client application.

There are no additional parameters for this hook.

Key: vma.on_action.poweroff

This hook is executed when a virtual machine is closed.

There are no additional parameters for this hook.

Key: vma.on_action.expire

This hook`is executed when a `soft expiray limit is executed in the virtual machine. Usually, this will be used to ask the user to restart as soon as possible to update a disk image.

There are no additional parameters for this hook.

Key: vma.on_state.connected

This hook is executed once a connection between the QVD Client and the server X-Windows, which is executed in the virtual machine, has been correctly established.

Key: vma.on_state.suspended

This hook is executed once the user closes the QVD Client and the X-Windows session is in a suspended state.

Key: vma.on_state.disconnected

This hook is executed when the X-Windows session is finished.

Key: vma.on_provisioning.add_user

When a user is connected for the first time. If the user does not exist yet, a new account is created for him in the virtual machine.

By default, the account is created with the command useradd.

The hook add_user lets an administrator modify this process and create the user account using an alternative method or a command sequence.

Key: vma.on_provisioning.after_add_user

Once the user account is created, this hook can be used to perform additional actions related to the configuration of the user account inside the virtual machine, such as the automatic configuration of an email client or other similar tasks.

Key: vma.on_provisioning.mount_home

By default, QVD mounts the first partition of the configured device with the entry vma.user.home.drive in the directory "/home" where the main user directory is created (by the hook add_user). If the partition does not exist, it is created on the fly.

With this hook it is possible to change this process to produce any other behaviour, such as mounting a directory /home from a server NFS.

If the log is not configured in the vma.conf of a virtual machine, it will remain registered by default in its own file in /var/log/qvd.log inside the virtual machine. This can be explicitly established, or changed, inside the file vma.conf in the the following way:

The level of the log itself can be one of ALL, DEBUG, INFO, WANR, ERROR, FATAL, OFF.

To review the log data written in a file inside a virtual machine, you will need to have access to the virtual machine in execution through the console:

If you are using LXC virtualization, it is often easier to access the log files directly from the server node where it is being executed. Remember that for an environment in execution, its filesystem is built as it is started and is mounted in /var/lib/qvd/storage/rootfs. This means that for any virtual machine it is possible to directly see the log files from the main host where it is being executed:

QVD also stores a backup copy of the overlay for any LXC virtual machine that is not correctly started. These security copies can be seen in /var/lib/qvd/storage/overlayfs and are usually saved with the prefix deleteme-, following a similar convention to the one followed for the successful naming of overlays. To obtain more information, seeoverlayfs.

Registering the activity remotely in a daemon that supports the syslog protocol can be desirable for several reasons. Firstly, it maintains the logs for all the virtual machines that have been configured like this in a place where access to the logs is easier and more logical. Secondly, in a situation in which the administrator may not have access the log of a virtual machine for some reason, for example, if it not being started, remote logging can help to identify the problem.

To configure remote logging, you will need a configured remote logging server and make some changes inside the disk image, in the file vma.conf of QVD and in the syslog configuration to send syslog messages to the remote logging server.

To show this we will use the link Rsyslog, which has become the default logging utility for many of the main distributions of Linux in recent years, including Ubuntu, SUSE and Red Hat, and it is reliable and easy to configure. Since QVD uses Log4perl, it should be independent from the destination logging daemon, so it could use these instructions with syslog-ng among other alternatives if necessary.

If rsyslog is not available in its server, install it the following way for Ubuntu:

Or, if it uses SUSE:

Once this is done, we will have to configure rsyslog to accept remote connections. In this example, we will use the link: Reliable Event Logging Protocol (RELP), since we consider that it is just for this, but of course you can use TCP or UDP as you prefer. To configure rsyslog to use RELP, create the file 30-remote.conf in the folder /etc/rsyslog.d/ and enter the following configuration:

This loads the entry module RELP and establishes that the server listens on the port 2514. Then it tells rsysllog to generate the log file name dynamically, depending on the host name of the client. The following line tells rsyslog to register all the messages in the file formed dynamically. Now, restart rsyslog:

Then, you will have to configure the QVD image to register remotely to this server. Inside the image QVD that you are going to use, create in the folder /etc/rsyslog.d/ a file called 00-remote.conf and enter the following configuration:

Make sure to enter the IP address or the host name of the logging server. This configuration will tell rsyslog in the virtual machine that it has to load the output model RELP and use the port 2514 in its rsyslog server. It will also send all the output (*.*) to this remote host.

Finally, edit the file /etc/qvd/vma.conf in the virtual machine and enter the following to tell QVD to leave its logs in syslogs:

With this configuration, the image must send the log of QVD to the remote rsyslog that you have configured. To check it, use the logger command inside the image and the output must be in the logs of the logging server.

QVD has a wide range of very specific configuration settings which control various components within the infrastructure. We discuss some of them here.

To change a QVD configuration parameter by means of the QVD CLI Administration utility, you can do the following:

It is also possible to obtain all the current database configuration settings and number them:

Finally, it is possible to delete a QVD configuration parameter of the database:

It is common to use the QVD CLI Administration utility to add new QVD server nodes to the QVD database. This can be done very quickly from the command line with the following directive:

The elimination of a QVD server node is equally as simple:

The QVD server nodes must be configured to use SSL. Currently, the only way of doing this is by using the QVD CLI Administration utility:

It is recommended that whenever possible you use a certificate signed by trusted CA.

You can easily add an OSF to QVD using the QVD CLI Administration utility if it is in a host that has access to the shared storage where the "images" are stored:

There is only one compulsory value to add an OSF, which is name. If the other parameters are left unspecified, their default values are used in their place. These are:

You can obtain a list of currently available OSF by doing the following:

Using the QVD CLI Administration utility, you can attach a disk image (DI) to any existing OSF inside the system. This process can take quite a long time, since apart from updating the database, the real disk image file is copied in the directory storage/images inside the shared storage.

On attaching a DI to a particular OSF, we keep the real disk separate from the image that will serve the final users. This means that you can make changes in the disk image and simply update the OSF, so that when a user reconnects the image, it is automatically updated without the user experiencing any disruption to the service.

Both path and osf_id are compulsory to add a DI. When the DI is added, the image specified in the path is copied in the read only storage area configured to store active DIs (usually /var/lib/qvd/storage/images).

You can obtain a list of currently available images by doing the following:

The DIs can be freely labelled with arbitrary chains. To label a DI as default, use the command di tag:

You can label DIs with any chain, not only default or head. This lets you use significant names for the tags, for example "software_bug_fixed", for use in the DI Tag field of the virtual machines.

Tags are useful, since they let you attach a new version of a disk image to an OSF without affecting anybody that is using the current image or default image for an OSF. This lets you implement a change and migrate specific virtual machines using a different OSF for the new image while it is being tested. If the image fails for any reason or does not meet the desired requirements, it is easy to go back to the default image and let its users continue working while corrections are made.

In order to tell a virtual machine that it must use a DI with a specific tag, we edit the VM to change its di_tag field. So, if for example we have just corrected a software error in a DI and we create the tag "software_bug_fixed", we can use this DI in a VM using the following command:

The next time the VM with ID 42 is started, it will use the DI with this tag.

It is common to use the QVD CLI administration utility to add and delete users quickly.

You can also list all the users of QVD with the list option:

Keep in mind that, as explained in the Installation Gide, it is not advisable to create a user whose username already exists in any disk image.

You can change a user’s password via the QVD CLI administration utility:

In the previous example, we are changing the password for the user of login guest. You will be asked to provide a new password.

Adding and deleting virtual machines via the QVD CLI administration utility is easy. You can specify the user and the OSF by ID or by name:

You can easily delete a virtual machine using the following command:

The QVD CLI administration utility can be used to start and stop virtual machines. If a particular filter is not specified, the action will start or stop all the virtual machines. This command is usually executed specifying a filter to identify the actual virtual machine that you wish to start or stop. Examples:

The balancing policy determines the node where the VM will start.

Virtual Machines can be marked as "blocked". When they are in this state, the QVD Client application will not be able to connect to the Virtual Machine. This task can be executed by an administrator to carry out an administrative task or when the HKD is unable to correctly manage a virtual machine. The following commands can be used to mark a virtual machine as "blocked" or they can be used to unblock a virtual machine that has been established in this state.

Check block and unblock the virtual machine in the WAT manual to obtain more information on how to configure this state.

The QVD CLI administration utility also provides options to connect to a virtual machine without using the client application. This is useful to debug an image that does not work in QVD. Currently, the supported options include the serial port console, SSH and VNC access. To access the serial console of a virtual machine, use the following command:

This will open a session in the serial port of the virtual machine with the 1 Id. If KVM virtualization is being used, the virtual machine needs to have the serial console activated: see for example -

Serial Console HOWTO for Ubuntu.

To enter a virtual machine by ssh, execute the following command:

This will open an SSH connection to the virtual machine called myVM using the username qvd. The virtual machine needs to have OpenSSH installed and configured.

If you are using KVM virtualization with VNC access enabled and you have vncviewer installed, you can execute the following command to open a VNC.

The VNC console is not available when LXC is used.

QVD includes the option to configure customized properties for a virtual machine that can be established and recovered via the QVD CLI administration utility. This is useful if you need to write your own behaviours or wish to take advantage of the VMA hooks (see the relevant section on this).

The customized properties are often used when you write your own plugins for the L7R, like the authentication modules or load balancer.

The customized properties are compatible with the configuration parameters: host, user and vm

To add a customized property, you can use the command _propset:

You can obtain the content of all the customized properties that have been established for a configuration parameter using the command _propget:

Finally, you can delete a customized property via the command _propdel: