For non-Dutch speaking readers: this is about a petition seeking to limit what information communication providers should retain in accordance to the EU Data Retention Directive.
It is only useful to sign this petition if you actually live in Belgium.

Voor al wie enigszins met z'n privacy begaan is: gelieve hier de petitie tegen algemene bewaarplicht voor internetproviders te gaan tekenen.

Photography is all about being in the right place, at the right time

I would like to point out that my last article was in no way meant to be critical towards libvirt, rather on the contrary. I think it's an awesome technology the way it provides a common management platform for various virtualization solutions available on Linux and even other platforms.

For reference, expensive proprietary virtualization solutions don't necessarily fair better.
I've in fact recently ran into a problem in a Vmware ESX / Virtual Center environment which, while rather different in manifestation, in the end was similar in nature: diverging state change in the environment and in configuration.

The Vmware problem surfaced after kernel changes on Linux guests, where, after rebooting into the new kernel and running the vmware-config-
tools script to rebuild the modules, nightly backups with help of the vcbmount utility would fail.
The only cryptic error message was:

Creating a quiesced snapshot failed because the (user-supplied) custom pre-freeze script in the virtual machine exited with a non-zero return code.


It didn't help that there wasn't any "user-supplied pre-freeze script" to begin with.

Searching for this error message returned lots of hits, several going at least one year back. However, aside from a few references to a documented Solaris guest issue, which was not applicable, none would actually provide any insight into what the problem might actually be. Unt
il I found following post on the Vmware communities site, which pointed out that
changes to the uuid.location weren't propagated properly to the vmx definition.

For the time being, the best way to work around this (in Linux guests) is to add another reboot right after rebuilding the vmtools modules.
Since you should be rebuilding
But Vmware should provide a proper fix their stuff, really. I've got this strong feeling that the libvirt bug will be resolved in less time than a year...

Because of my personal virtualization project, I have been working with virsh/libvirt/kvm a lot over the last year.
Once you start to do more advanced networking manipulations with libvirt, there are a few gotcha's to be aware of though.

The first issue is an actual bug: when you use 'virsh -c qemu:///system net-create' — with the mandatory xml definition provided as an argument, of course — the new virtual network is created just fine, but not saved out to disk into the /etc/libvirt/qemu/networks directory.
As a result, other virsh net-* commands return strange errors when you try manipulating the new network. For example, the net-autostart command will complain with:

libvir: QEMU error : internal error Failed to create symlink '(null)' to '(null)': Bad address

Realizing autostart is effectively configured by creating symlinks in the right place, I found that the symlink target did not exist when I saw this error. Searching for a fix I made a really trivial modification to the virtual network definition with 'virsh net-edit', adding a space into the temporary file, but this was enough to have the network definition actually written out to disk.

The other thing to keep in mind is to modify the xml definition appropriately, if you use 'virsh net-dumpxml' from an existing virtual network for ease of configuration.
There are at a minimum two more things to change besides the obvious changes of name and ip address range.

First is the bridge name, which is obvious if you consider that libvirt creates a new bridge for each virtual network you define, to connect the network to. And it won't cause much problems if you forget this because virsh returns an error if you forget it.

The other item is the network uuid, which can be simply removed; libvirt will generate a new one for you.
It should be equally obvious that you can't have two virtual networks with the same uuid, however virsh won't complain about that — but it will start behaving unexpectedly with the net-* commands if you forget this. Luckily, undefining the interface which I newly added with a duplicate uuid has fixed any resulting issues for me — and I've only forgotten this once.

Each of these issues may or may not be equally applicable to the virsh/libvirt/xen combination, but I haven't actually tested. That is for someone else find out and report back :)

So in three weeks time, two once large Unix vendors are gone — SGI on april 1st, and now Sun. SGI as a Unix vendor had been dead for years anyway, but still.

Today's announcement also kind of finalizes the answer to my wonderings last year. Sun somehow seems to have managed to send off MySQL into limbo, and it remains yet to be seen if Oracle would have any imperative to bring it back.

One thing I do find bothersome with the new situation is that at the moment I write this, the opensolaris.org website appears to be unreachable. Which might just be coincidence, but I do hope that neither Sun until the deal is finished or Oracle afterwards turn away from their current opensource backing positions.

... And so is computing.

At the beginning of last year, I finally bought a replacement for all the old junk that I was using as computer substitutes; a quad-core (Q6600) system with 4 GiB of memory.

For a couple of reasons, I set it up in a hurry, using software raid on two 160 GB harddisks, but last july I decided to redo it properly and at the same time consolidate as many as possible of the old systems I was using virtualization.
Until that time, I had been using VMware for virtualization at home, to be able to run appliances or historical VMs I had sitting around. This time I would try to move over to an opensource solution, if any could fullfill my needs.
Continue reading "The Times They Are a-Changin'"

This week brought some really nice weather. Too nice already for some people, it would seem.
While most people would likely enjoy a ride home on a sunny afternoon, for certain hotheaded ones the temperature appears to set their brains and blood boiling and remove the inhibitions for juvenile behaviour.
Driving home I encountered a truck driver hanging out of his window having a heated argument with a car driver standing straight up through his sunroof. I couldn't hear what they were arguing about, as it happened a few cars before where I stood, but in the meantime they were blocking the two lane drive. I'd almost be surprised if it wasn't one or the other accusing his adversary of doing exactly that, blocking his trajectory.
Luckily the scene didn't take too long and they drove on before others could join in on the argument.

One pattern that I've observed so far in all incidents of traffic aggression that I witnessed, is that at least one of the parties was accompanied by a female passenger. I have to wonder if female company is in fact an influencing factor…

° 16 08 2008

Last week I needed a way of converting a two-dimensional array, in perl, into a tree-like datastructure.
While seemingly trivial, the convoluted use of references when passing around arrays and hashes between perl function calls -- recursive calls, in this case -- made this a mind-boggling exercise to me. (the fact that I hadn't seriously used perl in the last eight years might have had part in that, too)

Below the jump is my implementation, debugging info left in and all. If it's useful for someone, that's great; if not, ... well, except for my mental sanity no harm was done in writing this, either :)
Continue reading "Perl hash tree helper"

Learning that the Linux Professional Institute offered a chance for taking exams at a reduced price during this year's FOSDEM, I decided to take a shot at the level 1 exams.
I was fairly occupied in the period before FOSDEM when I took that decision, but given that I've been using Linux heavily for over a decade, and after reviewing the objectives, I figured that I should be able to pass it without specific preparation.

Yesterday I received an email that indeed I did, so now I am officially a “Junior level Linux professional”.
I guess I should take a look at getting LPIC-2 sometime.
Continue reading "I'm junior now"

I've got internet at home again since yesterday. It sure makes life easier...

Last week has been a stressful one, for reasons I'll come back on later.
This week had started better, but since yesterday my Internet connection stopped working^[1] (for the same reasons). It isn't when until such thing happens that you realize how dependent you've really become on it, even for simple matters as looking up contact information.

[1] So this and the previous post were written from my with my parents-in-law.

One annoyance with the lilo bootloader that I've ran into a few times recently, is that it apparently turns any root configuration arguments into a device number. Which is then passed to the kernel at boot.
So if the kernel decides to assign a different device number to the supposed root device, your system may no longer boot.

Yesterday I once again ran into this: when I added an additional disk to a system, the LVM volumes which were on that new disk got assigned device numbers before the existing system LVM volumes.
Giving the problem a little thought, I realized that the solution — though silly — is really simple: add an “append="root=/dev/yournode"” directive to lilo.conf, and this boot-time argument will always override the root device set by lilo.

No more changing root devices for me…

I'm a bit puzzled why feedburner would be listing a blog search for Sylvia Saint as a reader of my feed earlier this week. Especially as I can't readily find my blog or feed in the search results.
(I guess this post could start bringing in search results)

Apparently she is a porn star (Wikipedia), and a prototype one at that: blonde and busty.

Ah, the things one can learn through reviewing website statistics...

For a while now I had been planning to move this blog a different server and URL; a URL that I would have full control over instead of the user directory it was deployed in.

I also had been longing for a different blog platform some time. While the primary reason for choosing Blosxom.PHP, that it did not depend on a database server, still held, I also had gotten tired of having to dig into it's code (usually in several places) for things that in my opinion should not require having to make changes all over the place.

So when the ageing server that held the old blog had temporary IO problems last weekend, I considered the time ready for making the move.
Continue reading "Blog migration"