software

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'"

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"

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…

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"

Christian, you forgot to mention the Linux kernel, where a member of the kernel team deliberately broke hardware support.
Thanks to Holger for these links, he has listed several more. I disagree with the suggestion that shipping the old firewire stack in the linux-extra-modules package is sufficient workaround; unless this is not prohibiting it from being included in the installer to support ethernet over firewire? (though in such case it will certainly have implications due to the fact that this package should be pulled in when the installer used eth1394)

So Adrian, you too may want to reconsider if Debian really does have less compatibility regressions than other distributions.

Someone asked on the PyGTK mailinglist if it is possible to reuse certain parts of a libglade window several times within an application.
It certainly is, and it's not even hard to do!

I've quickly written a demo application to show how it's done.

The user interface designed in glade is really simple, a textbox with two toggle buttons underneath. Activating one button will display a second, disparate textbox beside the original one. Deactivating it will remove that second textarea.
The other button will display and remove a copy of the first textbox which was there from application startup.
The full widget tree of this interface is shown in the first screenshot.

The actual code to the demo application is rather brief. Continue reading "PyGTK/glade object reuse"

First, a question: dear lazyweb, how do I completely disable non-SSL access with lighttpd? I can't seem to find how to have a lighttpd SSL-only configuration. (and only binding port 80 on localhost does not count for an answer)

On to the subject. While it's easy to add SSL to lighttpd and enable PHP (through fastcgi) — and Debian makes it even easier with it's lighty-enable-mod tool — if you only do it once in a blue moon then it's not exactly resident knowledge. So here are the steps to do it, on Debian Etch:

1. apt-get the lighttpd, php4-cgi or php5-cgi, and openssl packages
2. lighty-enable-mod fastcgi
3. if using php5, update the path to the cgi binary in /etc/lighttpd/conf-available/10-fastcgi.conf (it's preconfigured for php4)
4. lighty-enable-mod ssl
5. update the path to the SSL certificate in /etc/lighttpd/conf-available/10-ssl.conf
6. restart the lighttpd server

That's all there is to it. Well, strictly speaking there's a step 4a: install a certificate; but that's arguably not a part of the configuration process.
(for reference: openssl req -new -x509 -keyout /etc/lighttpd/selfcert.pem -out /etc/lighttpd/selfcert.pem -days 365 -nodes will generate a self-signed certificate)