Welcome to the virtual world!


About two months ago I informed the followers of this blog that I will now be working on SPICE project for Red Hat. Judging from the questions I was asked after that, I realized that not many people know about SPICE so I thought I write at least one blog entry dedicated to explaining what SPICE is all about. Before I get to SPICE itself, let me first introduce you to the world SPICE lives in.

Virtualization and Virtual Machines (VMs)


For some reason, I feel that I should leave the definitions to wikipedia and only quote it so that is what I am going to do:
"Virtualization, in computing, is the creation of a virtual (rather than actual) version of something, such as a hardware platform, operating system, a storage device or network resources."
"A virtual machine (VM) is a "completely isolated operating system installation within your normal operating system".Today, this is implemented by either software emulation or hardware virtualization".

Virtualization (of software and hardware platforms) is really nothing new and has been around since..well the the real thing itself: computers. There has been several implementations of different kind ever since and I are two main reason they exist and grow:
  1. Developing/testing software for hardware that you do not have. This makes virtualization softwares were attractive for consumer product manufacturers to be able to start the development of software soon after the plans for a particular product are finalized since it takes some time before they can manufacture enough prototypes for every developer and tester involved.
  2. Portability: In a typically VM setup, installation is done on drive images (files) rather than actual drives/partitions, which means you can carry or send your (virtual) machine anywhere you like.
  3. Ability to use multiple operating systems at the same time: Many Linux and Mac OS X users often need to run applications that are only available for windows and vice versa. Dual-boot is one solution to this issue but that implies you will only be able to use one OS at a time.
  4. Partitioning of a single host to multiple servers: Consolidation of many servers to a single host is a popular use case these days, done internally in many companies and also by hosting services. aka “The Cloud”.
Despite its big drawback, traditionally dual-boot has remained to be the preferred solution for many for a long time. The reason for that has mainly been the limitations of virtualization solutions, especially in terms of performance. However due to significant improvements in both hardware (built-in virtualization support and multi-core) and software, virtualization solutions have been gaining a lot of popularity lately.

Tools

Qemu + KVM


There are many such solutions out there, both Free and non-Free out there but the solution of our choice is Qemu. This awesome virtual-machine manager (a.k.a hypervisor) combined with Kernel-based Virtual Machine (KVM) and built-in virtualization extensions in modern CPUs is capable of providing such a virtual environment that puts the real thing to shame.

Qemu+kvm might be a very powerful tool, its still very much a power-user tool. For example you have to use long commandlines with different switches to use Qemu effectively. Worry not! There is another set of tools to help there:

libvirt


While Qemu+KVM might be an awesome solution, its still one of the many hypervisors out there and with some many people pouring into the virtualization industry, you can be assured that there will be a better alternative available sooner or later. libvirt not only abstracts you from hypervisors but also adds some really nice features on top of that:
  1. Manipulation (creation, deletion and modification etc) and monitoring etc of virtual machines on remote hosts, securely.
  2. Live migration of virtual machine(s) from one host to another.
Apart from the libvirt library itself, the libvirt package also comes with a very nice commandline tool called virsh that exposes libvirt API as convenient arguments. As you can probably guess from its name, virsh is a shell so if you can launch it without (command) arguments it will launch an interactive shell, awaiting your commands.

virt-manager


Neither libvirt, not virsh are tools that an end-user could be expected to use. Thats where virt-manager comes into picture. It basically provides the same functionality as virsh but unlike virsh, its designed for end-users and hence has a very user-friendly graphical user-interface. Here is some screenshots that should give you a good idea:



While virt-manager has nice UIs for everything related to VM management, it still leaves the remote access of virtualized (guest) OS/desktop to tools that are tailored for that, such as VNC and SPICE.

SPICE


SPICE in simple words can be described as very smart remote-access enabler for virtual machines. Oh wait, I was supposed to leave definitions to wikipedia:
"In computing, SPICE (the Simple Protocol for Independent Computing Environments) is a remote-display system built for virtual environments which allows users to view a computing "desktop" environment - not only on its compute-server machine, but also from anywhere on the Internet and using a wide variety of machine architectures."

SPICE was originally developed by Qumranet as a proprietary solution. Red Hat acquired Qumranet in 2008 and in December 2009 Red Hat open-sourced the protocol.

Now with definition and history lesson taken care of, lets talk about the real thing: tools. SPICE, the implementation is divided into 3 main parts:

Server

 

The SPICE server that runs inside the Qemu binary as a library. Its mainly responsible for authentication of client connections, relaying of graphics output of guest OS to the client using a Qemu feature called QXL and relaying of user input (mouse and keyboard) from client to the guest.

 

Client(s)


This is the tool that end-user should be concerned with. It provides a view into the guest OS (very much like the popular VNC).In the past there was only one SPICE client called, spicec. Due to various reasons (not embeddable, too low-level etc), it was deemed necessary to create a better client-tool. So for the past some months, our team has been working on a SPICE client Gtk+ widget called (surprise suprice) spice-gtk and helped in integration of it in vinagre (the GNOME remote-desktop client). I still haven’t used (or even built) spicec but from what I’ve been told, vinagre+spice-gtk are already much better than spicec in functionality so I guess I haven’t missed anything. Wait! Why am I telling you all this when I can just show you?

Just to be very clear here, spice-gtk is nothing specific to vinagre so if you want to have SPICE integration in your UI(s), you can do it very easily using spice-gtk. Apart from the C API, it also provides gobject-introspection and Vala bindings.

 

vdagent:


There are certain important tasks that spice-server needs to perform that it can not do so itself as it runs on the host rather than guest. A good example is copy/cut and paste between client’s host and guest desktop. For this reason, vdagent exists. Its a helper that runs inside the guest (and as such is installed from the guest). So making the copy&paste possible, it proxies the appropriate events to/from the SPICE client from/to guest windowing system through spice-server.

 

Whats wrong with VNC?


VNC has been around for a while now and in modern unix world, its considered as the remote desktop solution so its natural for people to ask: why create yet another solution for the same problem? The reason is that SPICE protocol has been designed to be very efficient on bandwidth usage and to satisfy the needs of a virtualized environment [1]. Recall QXL I mentioned above? QXL is handled/implemented as something called paravirtual devices in SPICE. Its probably appropriate to quote the related wikipedia definition here first:
In computing, paravirtualization is a virtualization technique that presents a software interface to virtual machines that is similar but not identical to that of the underlying hardware. 
So while a VNC server reads frames from video memory and sends (compressed though) the updated areas (if any) to the client, spice-server on the other hand presents the guest windowing system with an X driver that captures X protocol operations directly. That is what makes SPICE a lot more efficient at network usage compared to RFB protocol that VNC uses.

The end


I am really not good at explaining things so I’m sure I must have left-out some necessary details but worry not! We have a team of awesome hackers who can always help you with any issues related to SPICE. You can reach us either through our IRC channel or mailing-list. If you are attending the Desktop Summit 2011 in Berlin, you are in luck cause not only there is a talk about ‘Integrating virtualization into the desktop’ but also some of us will be attending the full duration of the conference so you can come and discuss with us in person.
If you are interested in readily available products based on these awesome virtualization tools, I suggest you have a look here.

[1] Actually, currently SPICE can only be used to access virtualized desktops, though one of our team members is actively working to make it possible to connect to normal/real desktops.

Comments

Osqui said…
Very interesting, thanks!!

One question, though: could SPICE substitute LTSP in a near future? I mean, LTSP in Fedora doesn't work, and there's no official plans to fix it. If SPICE could work with PXE in some manner (I don't know if I'm saying something stupid) in order to be able to boot diskless stations, it could be incredible, really.

Thanks
Pankaj said…
I've been following SPICE ever since redhat acquired Qumranet. It shows great potential but i feel development is a little slow. I'm also very keen on using it as a replacement for VNC on real machines (not VMs), and i feel such a feature will make SPICE much more popular than it is currently
Jon Nordby said…
Hey Zeeshan. Glad someone is giving the libvirt+spice stack some PR, it is pretty decent now and has great potential.

However, the screenshots you show of virt-manager are several years outdated, and especially the overview UI is much better and nicer now.
Jon Nordby said…
And btw, we have opened registration for workshop/BoF sessions for the Desktop Summit. Perhaps you or someone in your team is interested in doing a session?

https://desktopsummit.org/program/workshops-bofs
Richard Jones said…
Couple of things:

libvirt is really a lot more than just about hypervisor abstraction. It's also about managing the many problems, random incompatibilities, and gotchas in qemu itself. Such as the fact that command line arguments change in every release. Or the dance you need to work out which of -hda, -drive, -device etc will work with qemu today.

Secondly, don't forget libguestfs ...
Anonymous said…
@Osqui: SPICE isn't exactly relevant to PXE. PXE is how you build/boot systems, SPICE is how you view their remote displays once built and booted. For PXE, take a look at Koan and Cobbler:

http://magazine.redhat.com/2007/08/10/cobbler-how-to-set-up-a-network-boot-server-in-10-minutes/
Osqui said…
Thanks! I'll study if I can create a diskless thin-client environment with all this stuff
Unknown said…
Well, I think I finally get what is SPICE, but as @pankaj says, I wonder why not apply it on real machines as a replacement of VNC?

But this made me squirm "you can be assured that there will be a better alternative available sooner or later" I find that as likely as Linux been replaced by something else. Sure, it will probably happen at some point, but I wouldn't count on seeing it any time soon.

Cheers.
zeenix said…
Felipe,

1. You didn't read the footnote I think. :)

2. AFAIK KVM didn't exist before virt-tools came to existance. Also its not KVM that is being used but rather qemu+kvm.

3 KVM is not so unlike to be replaced, in fact I read somewhere (can't find it anymore :() that there is work underway on a replacement.
Melroy said…
I love SPICE much more (except the issues with copy/paste I currently have), but it's must faster than VNC imo.

Popular posts from this blog

clutter-gst

zbus and Implementing Async Rust API