This tutorial will cover installation and basic configuration of libvirt and QEMU to a state where it's possible to easily provision new VMs with WebVirtMgr. It will be a minimalist install with as few dependencies as possible to keep the host easy to maintain. WebVirtMgr is not perfect, but is the best lightweight web GUI around at the moment. See the GitHub page for more information https://github.com/retspen/webvirtmgr.

In this case a netctl config file named bridge0 is created. The bridge device will need to bind to an interface connected to the physical network and will become the interface which provides connectivity for both the host, and guest VMs (the physical interface it's self does not need an IP address). The configuration should be similar to bellow, virbr0 is already created by libvirt, so use virbr1 for the bridge name.

libvirt does provide functionality to create network devices on the host machine, however the libvirt Arch package has netcf disabled which provides this (netcf is Redhat developed and is very similar to netctl). For Arch the bridge device must be created using the netctl profile.

Enable unencrypted TCP connections. This is for simplicity, in anything other than a testing environment SASL should be enabled.

listen_tls = 0
listen_tcp = 1
auth_tcp=none

Start libvirtd in listening mode by passing the --listen argument.

# nano /etc/conf.d/libvirtd

LIBVIRTD_ARGS="--listen"

Enable and start the libvirt daemon.

# systemctl enable libvirtd
# systemctl start libvirtd

Now the daemon can be tested with a system or session connection via virsh. When connecting to system the libvirt daemon starts at boot with root permissions. A session connection will launch a libvirtd instance as the current user, taking that users permissions and some limitations compared to a system connection. More details can be found on the libvirt wiki.

The setup in this tutorial will use a system connection while storing VHDs in the libvirt user's home directory. This is because WebVirtMgr is currently only tested with (and hard coded to) a system connection, also keeping user data out of the root file system is a good idea. For instance, a btrfs snapshot of root shouldn't be effecting VHDs.

WebVirtMgr Setup

A Python virtualenv will be used to install WebVirtMgr (currently v4.8.8) and it's dependencies. This makes maintenance easier as the application and packages are installed in their own virtual root environment separate from the system.

# pacman -S python2-pip python2-virtualenv git

Continue the setup as the libvirt user.

A virtualenv named webvirtmgr is initialized in the home directory. The system site-packages are exposed as well to make the libvirt-python package available.

If the server starts then this command can be used to create a systemd service file to start Gunicorn on boot. The only differences are the absolute paths and addition of the --pythonpath attribute. Running Django with Gunicorn requires the project directory be on the Python path https://docs.djangoproject.com/en/1.5/howto/deployment/wsgi/gunicorn/.

With WebVirtMgr working there are some basic settings that are needed to get a VM running. Under the Interfaces tab the virbr1 bridge interface created earlier should be visible. To make this available for a VM to use create a new network under the Networks tab using the virbr1 interface in bridge mode.

A couple of storage pools will be needed for VHDs and ISOs. Under the Storages tab create a new "DIR" pool with the source as /home/libvirt/vhd and an "ISO" pool with the source as /home/libvirt/iso. Then it is simply a case of using sftp with the libvirt user to upload an ISO to boot a VM from.

Because WebVirtMgr is using the system connection to libvirt any VHD created here will owned by the root account. Also it is highly recommended to disable copy-on-write (COW) for the VHD directory if using Btrfs, this can be done by enabling the C attribute.

# chattr +C /home/libvirt/vhd

Because of the amount of small random writes a VHD will receive over time, the file will become heavily fragmented and reduce the performance of the VM.

Finished

Thanks goes to the WebVirtMgr developers for taking the time to create a nice lightweight GUI.