Index ¦ Archives ¦ RSS > Tag: en

Playing with libvirt

Estimated read time: 4 minutes

I've been playing with libvirt in the last two days. My motivation was that I saw:

  1. plain kvm is not that fast
  2. there is this virtio framework which aims to make it faster
  3. using virtio directly is hard, better not reinventing the wheel and just try libvirt

So if you want to try it yourself, you need to pacman -S libvirt, service libvirtd start. Check /var/log/syslog for error messages, in case it can't find some commands (bridge-utils, dnsmasq, etc.), install them.

If you want to create a new virtual machine, you need pacman -S virtinst. Then you can use something like:

virt-install --name=syncpkgcd-helicon --arch=x86_64 --vcpus=1 --ram=1024 --os-type=linux --os-variant=virtio26 --connect=qemu:///system --network network=default --cdrom=/virt/iso/frugalware-1.3-i686-net.iso --disk path=/virt/syncpkgcd/syncpkgcd.img,size=40 --accelerate --vnc --noautoconsole --keymap=us

See man virt-isntall for more info about the meaning of the switches. One trick: kvm can't handle the gfxmenu in our grub on the install cd, so you need to disable that. One way to do it is to use vim -b frugalware-1.3-i686-net.iso, search for "menu /boot", and change "gfx" to "#fx". Then you can run virt-install. It'll start the install in the background. The easiest way (for me) to connect to the console is to create an ssh tunnel to the server running the kvm machine (for example ssh -L 5900:localhost:5900 server), then run krdc localhost:0 on my own machine.

Next trick is that you need kernel support to boot from virtio disks (/dev/vda), that's enabled in frugalware-current.git but there were no rebuild yet, so you need to build it yourself for now.

Once the installation finished, the machine will be shut down. You can use virsh to start it. Here is a great summary about virsh subcommands. Something not to forget: if you want to automatically start the machine after the host booted, use virsh autostart $name.

(You can also do a service libvirt-guests add, that way all guests will be automatically suspended/resumed on shutdown/boot. Just to be clear: if you want the "resume if it was a proper shutdown, start if there was a power cut" feature: you need both init scripts because libvirtd will always start/resume autostart guests, but it will never suspend them on shutdown.)

If grub hangs after reboot, try creating a small (I used 32MB) separate /boot partition first, that should fix the issue.

virsh shutdown $machine won't work if you don't install acpid and enable it as well, so it's a good idea to do so.

The last trick: if you want to use the virt-manager gui from your local machine to manage a remote host, it isn't trivial to do so. First, it would try to login via ssh as root, and that's disabled by default. (And why would you enable it?). Also, even if you allow that, it would try to use nc -U which is supported by the openbsd nc only, the gnu nc does not have such a switch. Instead, we can use socat to connect to unix sockets. So I created a wrapper script under ~/bin with the following contents:

#!/bin/sh
if [ "$1" == "-U" ]; then
        sudo socat - unix-client:$2
else
        /usr/bin/netcat $@
fi

Don't forget to add PATH=what_you_want line to ~/.ssh/environment, and include the full path of ~/bin there. This way you can keep using gnu nc and you can also login as a user to manage your machines, as long as you set up nopasswd sudo for your user for socat.

Finally a mini-benchmark:

The SBU of yugo (i686 buildserver, a bit old HW) is 645 seconds, SBU of an i686 guest on helicon (c2q machine with 8g ram) is 264, SBU of the host build on helicon is 76.

I would call this usable (not right now, but once we sort out the kernel part). Finally something that is free software and is comparable to VMware ESX. :)

Update: I recently did the same install with 1.4pre1 (which installs -current, so the kernel is 2.6.36), the list of tricks you still need:

  • separate /boot (haven't tried without)
  • edit iso image to get rid of gfxboot (tried, still fails without)
  • some problem with grub, you need to manually add "(hd0) /dev/vda" to /boot/grub/device.map, then run grub-install /dev/vda

So no more custom kernel, boot from virtio works by default! :)


Anyremote

Estimated read time: 1 minutes

I've been testing anyremote during the last week. I'm aware that there is kanyremote and ganyremote available, but I wasn't really interested in those, since they would hide the glory details. :)

So I decided to give the server mode mode a try and I choosed okular as a test application. My commandline is:

anyremote -s bluetooth:19 -f /usr/share/anyremote/cfg-data/Server-mode/okular.cfg

Once I started the server on my notebook I could choose it in the midlet on my phone in the j2me client and it worked as expected.


Scripts used in the Python 2.7 rebuild

Estimated read time: 1 minutes

First, I could almost reuse the same set of scripts as described here. The only change I needed to do is that aborting the build loop after each fail is a waste of time, so now I did:

for i in $(cat ~/test.list)
do
        echo $i
        cd ~/git/python27/source/*/$i || continue
        sudo makepkg -t python27,current -C
        git clean -x -d -f
        git checkout -f
        sed -i 's|python>=2.6|python>=2.7|g' FrugalBuild
        if bumppkg -t python27,current --rebuild "- rebuilt with python-2.7"; then
                repoman -t python27 -k push
        else
                echo $i >> ~/failed.list
        fi
done

Then investigated the failed builds manually.

Oh, and obviously I no longer had to build the x86_64/ppc fpms manually, I just enabled syncpkgd for the python27 WIP repo.


Next RTF fix: tables at the start of a document

Estimated read time: 1 minutes

This was almost two days ago, but... So I got the next problem report from OS, where he attached a sample document which had a table at the beginning. The document text was exported but no the table structure. (So if you had at least one line of text before the table, the bug was not there, that's how I did not notice it.) The one-liner fix is now in the CWS and it's backported to ooo-build master as usual.

Four RtfFilter fixes

Estimated read time: 1 minutes

During the week I got some feedback from Oliver Specht on my GSoC work. I decided to dedicate a whole day to address those issues (these were all regressions compared to the old RTF exporter). Here are the results:

  • Numbering indentations were problematic, this is now fixed.
  • Outline numbering was missing, fixed as well.
  • Explicit character style support was missing, I now implemented it.
  • Finally (which was the most time-consuming), text frames were now exported, this is now implemented, too.

One remaining question is that he mentioned something is problematic with the table of contents export, but I could not reproduce the bug so far.


Globalsat BT-338X GPS

Estimated read time: 1 minutes

Yesterday I bought a cheap GPS data logger / receiver, and given that the attached install CD did not support Linux, I'm collecting some hopefully useful links here.

Putting everything together, to get the log from the device using bluetooth I first had to create an rfcomm interface, as gpsbabel does not support bluetooth natively:

# rfcomm bind 0 00:0D:B5:38:BA:C6

Then to download and erase the log from the device:

$ gpsbabel -i dg-100,erase=1 -f /dev/rfcomm0 -o gpx \
        -F $(date +%Y-%m-%d).gpx

The gpx format is fine in case you want to later reuse log with digikam's gpssync plugin (available from kipi-plugins).

Now in case you want to convert it to kml to show on Google Maps:

$ gpsbabel -i gpx -f $(date +%Y-%m-%d).gpx -o kml -F $(date +%Y-%m-%d).kml

Finally release the rfcomm interface in case you don't need it anymore:

# rfcomm release 0

Update: there is also a gui which can be used to enable logging of altitude info, etc - just trivial patching is needed and it works with BT-338X as well.


Upgrading to Haven

Estimated read time: 1 minutes

I just upgraded my box at work to Haven, here is a short post to mention two links:

  • ATM you need to manually upgrade nvidia-173xx if you have it installed (after -Syu) due to lack of xorg-server-1.8 support.
  • I needed this xorg config tweak to get my up arrow working again.

Other than that, I removed my xorg.conf and instead I put this to the xorg.conf.d dir. I also added "nouveau.modeset=0" to /boot/grub/menu.lst.

What else.. ah yes, I needed to change the keyboard model to evdev in the KDE System Settings.

Other than that, it went fine. :)

Update: the nvidia-173xx part is now fixed in both current and stable.


openoffice.org 3.3 early snapshots

Estimated read time: 1 minutes

In case you got bored and you want to try something blending edge, have a look at my ooo33 repo.

It contains an early snapshot of OpenOffice.org 3.3 (+ ooo-build patches, of course), including this work.


googlecl and geeqie

Estimated read time: 1 minutes

I recently tested two new Frugalware packages.

googlecl is a commandline utility, I wanted to try it out as it has browser-based authentication, which is supposed to be compatible with Google Apps, while the API-based method used by picu is not. To make it short, in case you are in a directory containing photos for an album and you just want to upload all of them to an album named after the directory name, you need:

google picasa create --title $(basename $(pwd)) *.jpg

The other package I recently tested is geeqie, it's a replacement (see history here) for gqview I usually use to watch a lot of photos in a directory. And yes, they seem not to break any of the nice feature of the old gqview project, good work! ;)

Update: there is a patch to add sync support, it's usage:

google picasa post --title $(basename $(pwd)) --sync *.jpg


chkdep improvements

Estimated read time: 1 minutes

Yesterday I finally had a look at how chkdep removes duplicated dependencies. The whole idea behind the removal is that in case ldd says a package depends on libfoo and libbar + we know from pacman that libfoo already depends on libbar, then there is no point adding libbar to depends in most cases.

The old code did the followings: it searched the depends of the packages found by ldd and in case a depend was found in the depend list of an other depend then it removed the depend from the list. The problem with this is that in case foo depends on bar depends baz and ldd finds foo and baz only, then baz won't be removed.

The new code does the same but depends are detected recursively to avoid the problem mentioned above.

As a result, makepkg -a output should be less noisy. ;)

© Miklos Vajna. Built using Pelican. Theme by Giulio Fidente on github.