I’ve been receiving a lot of questions lately from people wanting to use libvirt with virsh and not wanting to use a GUI (e.g. virt-manager). They’ll get gung-ho and install libvirt and start up virsh and be confronted with an error almost right away. Obviously from a user perspective, this is a bad experience so I think a little background is in order.

libvirt runs in two modes called system and session. These terms are identical to D-Bus so if you are familiar with that just think in those terms. If not, system is the instance that runs as a system daemon. It has an init script at /etc/init.d/libvirtd and will run as root. The session instance runs as a normal user. It is not started at boot time but dynamically by someone using virsh. The default when running virsh as root is to connect to the system instance. The default when running virsh as a normal user is to connect to the session instance. This is why people say their virtual machines have disappeared or they can’t connect typically. There are four ways to connect to the system instance as a normal user:

  • virsh -c qemu:///system
  • virsh and at the prompt connect qemu:///system
  • export LIBVIRT_DEFAULT_URI=qemu:///system and running virsh
  • edit /etc/libvirt/libvirt.conf and set uri_default=qemu:///system

Now if you haven’t built libvirt with PolicyKit support, by default only root will be able to communicate with the system instance. You will have to edit /etc/libvirt/libvirtd.conf and change unix_sock_rw_perms to something more open like 0770 or 0777 (the former will require changing unix_sock_group to a group your user is part of). Then restart libvirtd to get the new permissions.

The last issue to befall people relates to libvirt’s recent switch to using XDG_RUNTIME_DIR and XDG_CONFIG_HOME from the XDG Base Directory Spec. The defaults for these are $HOME/.cache/ and $HOME/.config/ respectively. The issue that gets people is that your X session manager creates these directories for you if they don’t exist but libvirt does not. So for people logging into a user that never uses X, they won’t have these directories. As a result when exiting virsh you will get an error that it couldn’t save your command history. Additionally you will not be able to start a session instance without these directories present. The simplest fix is to just do mkdir $HOME/{.cache,.config} and all should be well. Note: This last issue is now resolved for the forth coming 0.10.0 release.

Users of qemu-kvm may have noticed that as of 0.15.1 it has a new dependency on sys-apps/seabios from the Coreboot project. Previously we used the pre-built versions that shipped with qemu-kvm, however this version is typically out of date and has recently caused problems for some users. Ubuntu and Fedora have switched to not using the pre-built versions and building their own versions of all the binary blobs recently as well so for Gentoo we’ll do the same. The issue however is that some of these can only be built with a x86 toolchain so we will have to come up with a solution for ppc. Any suggestions are welcome.

NVIDIA has just pushed out their first beta of the 290.x series drivers and this should be seen as good news for Gentoo users. Several bugs that I’ve pushed upstream from Bugzilla reports about the 280.x and 285.x series have been fixed. This should be the first series that Gentoo will support with xorg-server 1.11 and Linux 3.0. Additionally NVIDIA has built in a workaround for users using a noexec mounted /tmp when executing 32 bit OpenGL apps on a 64 bit kernel. Users should be aware that the workaround brings in performance implications but at least your app won’t crash. Many other little issues were resolved as well so I am inclined to bump the version in the against our typical policy of not supporting beta releases. Be aware however that if I see an abnormal amount of bugs with the beta release it will be quickly masked.

kvm changes in Gentoo

November 22, 2009

Since I got saddled with maintaining kvm without really having the desire (I use it but not all that often) and not really having the time to maintain it, I asked for someone to take over maintainership. Unfortunately I didn’t get any replies so the package has remained fairly unmaintained and dead-ish. Well I’ve decided today to take some time and clean it up a little bit and get it up to speed a little. However, this means that there are some changes coming.

We will use qemu-kvm releases and will no longer rename everything to make it play nicer together. External kernel modules won’t be supported and you’ll be expected to build the right settings into the kernel. If you want to use the external kernel modules, that’s up to you. qemu and qemu-kvm will be blockers since they will overlay greatly.

Really the optimal thing would be for a group of people to take over kvm and qemu and maintain them together.

NVIDIA legacy drivers update

November 13, 2009

As I previously noted, the 96.x.y and 173.x.y series had not seen any updates yet for xorg-server 1.7 compatibility, however today that has changed. They both saw updates late last night from NVIDIA and now those drivers are available in the Gentoo tree so feel free to give them a try.

MythTV 0.22 is out

November 8, 2009

As many may have already known, MythTV 0.22 is officially out. Slashdot is late to the party to report the news, however Gentoo does have ~arch ebuilds available in the tree for MythTV and all officially supported plugins. In the future I may add an ebuild as well for mythstream since it is a fairly popular plugin.

Some known issues include compilation problems on x86 as a result of PIC support, the issue is being looked into actively. For this upgrade, you must manually upgrade your database however the process is pretty painless.

If you run into any other issues, please file a bug and I’ll do my best to get to it.

As always happens when we see a new xorg-server release people start to wonder why the Gentoo ebuilds for nvidia-drivers have blockers for the new release. To help clarify this I’ll post an ASCII table showing the current support.

driver series   maximum ABI
-------------   -----------
71.86.*         2.x
96.43.*         5.x
173.14.*        5.x
190.*           6.x

xorg server     video ABI
-----------     ---------
1.7.*           6.x
1.6.*           5.x
1.5.*           2.x

As you can see from the above, the 71.86.x series has gone into very limited maintenance mode. I would be surprised to see very many updates, if any at all to it in the future. However, for users of the 96.43.x and 173.14.x series, NVIDIA has confirmed to me that there will be an update to the latest xorg-server ABI change. This update though does not have any definite dates so I can’t provide any. I recommend users of that series stay with xorg-server-1.6.x releases for the time being so they can have a smooth X experience.

Improved VDPAU abstraction

October 28, 2009

Recently, Aaron Plattner from NVIDIA announce libvdpau 0.2, which a wrapper for driver specific VDPAU implementations. You may have noticed that nvidia-drivers shipped a libvdpau.so library for a while now for apps to link against while placing their actual implementation in libvdpau_nvidia.so. Newer ebuilds of nvidia-drivers will no longer install libvdpau.so, nor any of the headers and install will rely on this being installed. Other applications, like MythTV will instead depend on x11-libs/libvdpau.

In addition to this change, there’s a new package called vdpauinfo in the tree. Some people might know it from the NVNews forums as vdpinfo. However, Aaron got the author’s permission to add it to freedesktop.org and rename it to vdpauinfo to match the library.

nvidia-drivers 190.x

October 28, 2009

NVIDIA has officially blessed the 190.x driver series to replace the 185.18.x series. Release highlights include:

  • xorg-server-1.7 support
  • OpenGL 3.2 support
  • VDPAU decoding of MPEG-4 Part 2, DivX 4, and DivX 5 depending on your GPU
  • Support additional GPUs in the GeForce GT series

For more details read their release notes, here.

Gentoo has had a few different developers maintaining “unofficial” drivers in the 190.x series. However there’s a few outstanding issues with those ebuilds that still need to be resolved before they’re unmasked. I’ll hopefully push 190.42-r2 unmasked later on this evening.

In an attempt to improve cross-distro support, I have been considering for some time now reworking the way the current dm-crypt setup in Gentoo works and making it work more like Debian, Ubuntu, Red Hat, Fedora, and CentOS do. Effectively the syntax they use is that of fstab, however its in a new file called /etc/crypttab. This file is formated in the following style:

/dev/VolGroup00/data    crypt-data    none           luks # Password style LUKS
/dev/VolGroup00/tmp     crypt-tmp     /dev/random    tmp  # sets up /tmp for each boot having a fresh key
/dev/VolGroup00/swap    crypt-swap    /dev/random    swap # sets up swap for each boot having a fresh key
/dev/VolGroup00/other   crypt-other   /dev/sda       luks # uses /dev/sda as the key source

The partitions above would all be referenced by /dev/mapper/crypt-NAME. As you can probably guess the above configuration is not an exhaustive iteration of all the configuration possibilities. I am merely trying to investigate if this is something that people would be interested in before I code it. I’ve had this idea kicking around in my head for over 3 months now (in fact I e-mailed the other base-system maintainers about it at the start of March) but I’m terrible at keeping up with my blog. In fact, I’ve still got some parts of my original council platform from LAST year’s election still sitting there as draft posts.

But back to dm-crypt. For more information, look at the Red Hat crypttab(5) man page. While it says there are no options for LUKS, they have added automatically added checking for LUKS and using that instead of the pre-LUKS crypt bits.  That being said, the Debian based version apppears to map bettter for us since it has a lot more options, Debian based crypto crypttab(5). Let me know what you think.


Get every new post delivered to your Inbox.