edin.no-ip.com

This mini-HOWTO will give you some idea about using KVM handily with the help of libvirt - The virtualization API (http://libvirt.org/), where an ultimate goal is using virt-manager (http://virt-manager.et.redhat.com/) in order to provide similar MUI (management UI) and feature as VMWare.

The main idea of using libvirt is because of its handy virtual client management style. Besides using libvirt, we will need to use CLI and input corresponding parameter to start the virtual client manually (every time!), or prepare a lossy startup script for reuse; libvirt can give a hand for virtual client installation, profile create and management (in XML style so easy to understand and editable), and even instant start/shutdown/etc action.

Long story short, libvirt is much like a middle-ware between low level KVM/XEN/QEmu interface and high level virt-manager MUI.

First of all, I will assume that you have some knowledge about what is KVM and how to let it function on Debian sid. I will not detail them once again within this mini-HOWTO. In order to have more general idea, please refer to here.

Prepare your Debian sid

Since KVM and libvirt is still under actively development, I will suggest using Debian sid in order to obtain the latest (relatively) stable packages.

Before you start installing packages, please ensure that you have already configure you Debian APT sources correctly, or refer to here.

I will assume you have KVM install and functioning correctly. Run the following command for additional packages installation:

Setup your hardware and network

Once again, you need to ensure your system and network are well configured for KVM, or else please refer to here.

NOTE! The latest Debian sid KVM package coming with a handy init.d script, which will help you modprobe correct KVM kernel module depending on your hardwares. It is a very simple helper: if you like it, use it; or else you can just feel free to forget about it :-p

Start libvirtd automatically

All handy magical staffs from libvirt are handled by its daemon: libvirtd. You can start/stop it by /etc/init.d/libvirt-bin start and /etc/init.d/libvirt-bin stop. BTW, before that we need to configure its parameter or else it will never start. Edit /etc/default/libvirt-bin as below:

Create KVM client disk image

Let's create the directory and disk image for next section:

When using virt-install (which will discuss in next section), client disk image can be created automatically. BTW, virt-install use raw as default disk format, which will preserve ALL required disk space during image creation. This may not be our cup of tea, since qcow2 would be much flexible and powerful, and the main point is the size will be dynamically expend on the fly. On the other hand, as libvirt is only acting as middle-ware and KVM support for qcow2, there is no problem if we are using disk format other than raw.

Start client installation with virt-install

The is the first magic part of libvirt. Assume you hope to install Debian stable in this KVM client (prepare you debian-40r3-i386-netinst.iso in /srv), run the following command to start the client installation with virt-install (you should run virt-install --help for more detail of this configuration). The client will then bootup and so you can start your installation as normal:

NOTE! You should run the above command within X, or at least running remotely with putty + xming activated. Else the installation GUI will not able to start up.

If you carelessly close the installation GUI or being kick away accidentally, don't be afraid. Just run the following command and you will get back to the screen:

virt-viewer demo

After installation is complete, check /etc/libvirt/qemu if a new file called as demo.xml exists. It will contain the configuration of your newly created client, in XML format. Whenever you start the client by running virsh (will discuss in next section) or by the GUI of virt-manager (since it is now crazily unstable so will not discuss within this mini-HOWTO), libvirt will read this file, phase the configuration, prepare corresponding parameter, and call kvm finally (as like as what we did in here).

Manage client instant with virsh

Here is the next magical section of libvirt. Similar as VMWare's vmware-run, you can start/shutdown/destroy/list/etc with libvirt's virsh. For more detail, please refer to virsh --help and man virsh. Here I will give you some general idea:

• virsh start domain: Start a predefined domain (virtual client with profile, e.g. demo in above case).
• virsh shutdown domain: Shutdown a predefined domain (may not be successful, always check the result with ps aux | grep kvm).
• virsh reboot domain: Nothing at all, just reboot a domain.
• virsh destroy domain: Terminate a domain (always successful, as like as kill -9).
• virsh autostart domain: Autostart a domain. It will create a symbolic link from /etc/libvirt/qemu/example.xml to /etc/libvirt/qemu/autostart/example.xml (i.e. a simple delete of such link can deactivate the autostart of domain).
• virsh list: List domains.

I haven't test all of the features yet... E.g. I am interesting about how virsh migrate functioning... If you have experiences about the rest of commands, please feel free to let me know :-)

Connect to the client

There is many different method to connect your client instant. The most simple way is hit virt-viewer domain, a GUI console will pop up as like as what VMWare provide. BTW, you will need to run this within X or a X forward enabled remote host.

The other solution is using VNC. Try to figure out the port of client with ps aux | grep kvm. It will show out an -vnc option, so you can connect it with any VNC client, e.g. xvncviewer :0 (running from localhost).

A final solution is using platform dependent remote management method, e.g. SSH for Linux and Remote Desktop for Windows. Usually this is the most stable and efficiency method, but surly that you need the help of above either method to setup this level of remote control correctly.

FAQ

Q. How can set some domains as autostart during system startup?
A. Symbolic link the domain configuration XML to /etc/libvirt/qemu/autostart, e.g. ln -s /etc/libvirt/qemu/demo.xml /etc/libvirt/qemu/autostart

Q. I have an existing virtual client which hope to migrate to libvirt, how to do so?
A. Usually virt-install require you to provide both: 1. client disk image file, and 2. CDROM (or ISO image) for system install. The domain configuration will be created automatically after this process is complete. So a tricky tips for migration is: 1. prepare your client disk image (or even convert it with qemu-img convert), 2. start virt-install with this image but MISS OUT the -c (CDROM) parameter, 3. answer CDROM location as /dev/null when virt-install asking for it, and 4. terminate the installation when it gone crazy (e.g. with virsh destroy domain). Therefore libvirt will create the domain configuration file for you.

Q. I hope to connect my client with VNC from a remote host, how to do so?
A. The default VNC setup of a newly created virtual client will bind to localhost only (127.0.0.1), therefore you can't access it though public network. In order to change this behavior, edit the domain configuration file, e.g. /etc/libvirt/qemu/demo.xml, search for the <graphics> section, and update it based on your needs (e.g. edit it as <graphics type='vnc' port='-1' listen='0.0.0.0'/>, where port='-1' means it will search for a free port above 5900 automatically, port='0' means port 5900, port='1' means port 5901, and so on).

Q. You have mentioned about virt-manager. I check their website and it looks great! Why don't we use virt-manager but virsh directly?
A. The reason is very simple: it is completely not stable enough for daily usage. The latest version (2008-05-30) will crash and can't even startup. Even some previous version are able to operate, their functionality is crazily trim down based on usability concern and so not flexible enough, e.g. you can't specific the disk format of client image but force as raw, can't fake the installer so not able to migrate existing client, not able to complete the client creation due to buggy UI, and so on. virt-manager should be the ultimate goal as far as compare with VMWare MUI; BTW, it is still too early for production :-(

Update (2008/07/03): I don't always use virt-manager but document is now in here.