Blog Article:

OpenNebula for Virtual Desktops

Carlo Daffara

Sep 20, 2013

In our experience as providers of private clouds based on OpenNebula, the single most common request among small and medium enterprises is the deployment of virtual desktops, both in terms of converting existing desktops and moving them to OpenNebula or for the creation of custom environments like computer classrooms for schools. This is, in hindsight, not difficult to explain: a cloud infrastructure brings a set of management advantages that are clearly perceived by end users that are frequently facing IT problems like blue screens, viruses and stability problems. Being able to move from one place to the other while maintaining the desktop VM active, rebooting into a previous snapshot before a virus infection or in general cloning a “good” master VM are substantial advantages especially for smaller companies or public administrations.

We found out that the combination of OpenNebula and KVM for the hypervisor to be especially convenient, and we deployed several small clouds serving small groups (5 to 10) desktops with great success. If you need to start from an existing desktop, the easiest approach is through an external software tool like VMware Converter, with the recommendation to avoid the installation of the usually enabled VMware tools (totally useless within KVM); apart from the use of Converter there are slightly more complex approaches based on tools like clonezilla (a good summary can be found here). The performance of converted machines is however not optimal, due to the lack of the appropriate paravirtualized drivers for I/O and network – so the next task is to convince Windows that it needs to install the appropriate drivers. To do so, download the latest Virtio binary drivers from this site, load the .iso image in OpenNebula and register it as a CDROM image. Then, create a small empty datablock with the following configuration:

Screenshot 09192013 042644 PM

Then create a new template for the Windows machine, linking as images the converted Windows disk, the small VD image and the Virtio ISO image. Set the network device as “virtio”, and reboot. After the completion of the boot process, enter into the Windows control panel, system and in the device window you will find a set of unidentified hardware devices- one for the virtual SCSI controller, one for the network card and a few additional PCI devices that are used to control the memory ballooning (the capability to pass real memory usage to the hypervisor, so that the unused memory can be remapped to something more useful). For each unidentified device perform a right click and install the drivers by selecting as source the virtio cdrom. Shutdown the machine and remove from the template the small VD disk and the iso image, and now you have a fast and accelerated Windows image ready for deployment.

Now that we have our VDI raw material, we can think about how to deploy it. In general, we identified three possible approaches:

Screenshot 09192013 125829 PM

The simplest approach is simply to load the VM images of each desktop inside of OpenNebula, assign a static IP address to each VM and connect using RDP from a remote device like a thin client or a customized linux distribution. The advantage of this approach is that RDP allows for simple export of local devices and USB ports; recent improvements to the protocol (RDP7 with RemoteFX, used in Windows 7 and 8) allows for fast multimedia redirection and several improved capabilities, already implemented in open source clients like FreeRDP. The simplicity of this approach is however hampered by the fact that this capability works only if Windows boots successfully, and if there is no interference in the login process.If something happens it is necessary to connect out-of-band to the console (for example using the integrated VNC console in Sunstone) and solve any problem that may prevent the successful startup of the virtual machine. This approach is also limited to Windows machines, so that if you have a mix with different operating systems you are forced to connect with different tools.

A more flexible approach is the use of the SPICE protocol. Originally created by Qumranet and released as open source after the acquisition of the company by Red Hat, currently integrated directly within KVM. It supports multimedia, USB redirection and several advanced features; it does have drivers for both Windows (here) and Linux (installing the xorg-video-qxl drivers). We found that several Linux distributions require a small additional file in the /etc/qemu directory called ich9-ehci-uhci-cfg (that can be found here) for USB redirection to work properly; after the addition, add to the Windows template the following libvirt snippet:

RAW=[
  DATA="<qemu:commandline>
     <qemu:arg value='-readconfig'/>
     <qemu:arg value='/etc/qemu/ich9-ehci-uhci.cfg'/>
     <qemu:arg value='-chardev'/>
     <qemu:arg value='spicevmc,name=usbredir,id=usbredirchardev1'/>
     <qemu:arg value='-device'/>
     <qemu:arg value='usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3'/>
     <qemu:arg value='-chardev'/>
     <qemu:arg value='spicevmc,name=usbredir,id=usbredirchardev2'/>
     <qemu:arg value='-device'/>
     <qemu:arg value='usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3'/>
     <qemu:arg value='-chardev'/>
     <qemu:arg value='spicevmc,name=usbredir,id=usbredirchardev3'/>
     <qemu:arg value='-device'/>
     <qemu:arg value='usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3'/>
  </qemu:commandline>",
  TYPE="kvm" ]

to have 3 redirected USB channels. Start the Windows VM and connect through a suitable SPICE client like Spicy, and you will get your connection, audio and all your USB devices properly working:

This approach works quite well – the VM is stable, performance within a LAN is quite good with no visible artifacts. USB redirection is stable, and it is possible to compile KVM with support for Smart Cards, useful for environments like hospitals or law enforcement where a smart card is used for authentication or for digital signatures.

The last approach is through a separate VM (again, inside of OpenNebula) that perform the task of “application publishing”, in a way similar to Citrix. We use Ulteo, a French software system that provides application publishing and management through an integrated web portal. You can connect Windows servers or linux machines; if you need to publish applications from Windows you can either use the traditional Terminal Server environment, or the much cheaper TSplus application that provides a similar experience. After installing the Ulteo DVD inside of an OpenNebula VM, you end up with a web interface to select the application you want to publish:

adm2
After the configuration you simply point your browser to the Ulteo portal interface, and you get a personalized desktop with all your Linux and Windows application nicely integrated.

For a more in-depth presentation, including specific I/O advice on hosting VDI-specific virtual machine, I hope you will join me during the first OpenNebulaConf in Berlin next week. See you there!

4 Comments

  1. Alexander

    Thanks for the article! Have you tried the solution 2X as an analogue Ulteo?

    Reply
  2. Carlo Daffara

    I have tried 2x in the past, but I found no open source server available (just a free trial, that is clearly marked as unsuitable for production).

    Reply
  3. Alen Xu

    Hi, may I ask where should I insert these codes,

    RAW=[
    DATA=”

    “,
    TYPE=”kvm” ]

    Reply

Trackbacks/Pingbacks

  1. Blog OpenNebula – Flexible Enterprise Cloud Made Simple » Archives » OpenNebula Newsletter – October 2013 - [...] and OpenGL). Another even more important contribution by Carlo has been summarised by him in this blog post, on…

Submit a Comment

Your email address will not be published. Required fields are marked *