Zugschlusbeobachtungen

In the last few days, I found the time to spend some with KVM and libvirt. Unfortunately, there is a subject that I haven’t yet found a satisfying solution: Naming of block devices in guest instances.

This is surely a common issue, but solutions are rare. Neither an article on Usenet (in German) nor the German version of this blog article has found solutions for the main question. I should have written this in English in the first place and am thus translating from German to english, hoping that there will be some answers and suggestions.

KVM is quite inflexible when it coms to configure block devices. It is possible to define on the host, which files or whole devices from the host should be visible in the guest. The documentation suggests that devices should be brought into the guest with the virtio model, which needs suppport in the guest kernel. Importing a device as emulated ATA or SCSI device brings a performance penalty.

The devices brought into the guest via virtio appear in the guest’s dev as /dev/vd<x> and do also have their corresponding entries in /dev/disk/by-uuid and /dev/disk/by-path. The vd<x> node is simply numbered in consecutive order as hd<x> and sd<x>. /dev/disk/by-uuid is the correct UUID of the file system found on the device, at least if it’s a block device partitioned inside the guest and formatted with ext3 (I didn’t try anything else yet). The terminology of the /dev/disk/by-path node is not yet understood, and I am somewhat reluctant to assume the PCI paths of emulated hardware as stable.

Linux policy routing is still incredibly painful if one wants to have more sophisticated routing than just “take source and destination IP address for the routing decision”. The mechanisms that have been in use seven years ago still work though, and I didn’t find any possibility to do it any easier. In this article, I’ll try to explain the “old” mechanisms and hope that somebody from lazyweb will comment and say “it can be done so much easier”.

This is a translation of the Usenet article <gu48cs$rul$1@news1.tnib.de> in de.comp.os.unix.networking.misc in the hope that the english-speaking blogosphere can give additional insights.

I haven’t been using ATM on Linux for some six years now. I neither have access to an ATM network any more nor do I have ATM hardware any more. Therefore, I plan to remove ATM support from ifupdown-scripts-zg2 in the next release which will be done in the next few weeks.

If anybody does still use ATM on Linux in conjunction with my scripts, you might want to offer help with the package if you want to have continued ATM support in ifdown-scripts-zg2. I cannot test the code any more and therefore cannot maintain it in the future.

In the last few weeks, I spent quite some time wondering about how to arrange the hard disk layout of my productive systems in the future. This article outlines my thoughts and would like to ask the lazyweb for comments.

I try to keep my Debian servers as identically as possible, making it possible to talk non-linux persons remotely through the system without having to worry about this particular box’ configuration.

A few months, I blogged about the pains I had with my nVidia FX 5200 graphics card, Debian and current kernels.

I have solved the issue in the mean time and would like to document what I did. This has been updated to reflect driver 173.14.20 from July 2009.

My home workplace is slowly and steadily mutating into a never ending story. I do not remember blogging every aspect of it, but after three graphics cards, an even older mainboard and two DVB-S-Cards, my home workplace PC currently does what I expect it to do: Run Debian unstable, drive two 20 inch DVI TFT monitors with 1600x1200 pixels each and receiving DVB-S transmissions. I do not think that these are exaggerated expectations, but it took over three months to find a combination of hardware which will actually do what I want.

The hardest part was finding a AGP graphics card which can drive two DVI monitors with 1600x1200 pixels each. After failing with two different Matrox cards (the G550 not being able to do 1600x1200 pixels if the monitors are connected via DVI), I finally settled on a used GeForce FX 5200. In the beginning, the binary nVidia module didn’t hurt as much as I expected. Unfortunately, this rapidly changed with the 2.6.27 Linux kernel.

Das Schicksal des Usenet-Teilnehmers hat einen T-Mobile Web’n’Walk-Stick (das schwarze Modell) in der nicht gesimlockten Version in meine Hände gespült. Auf sowas war ich ja immer schon scharf, weil ich mir von dem per USB angebundenen Gerät einen etwas stabileren Betrieb erhofft hatte als von meiner jetzt doch schon etwas älteren, nicht HSDPA-fähigen PCMCIA-Karte gewohnt bin. Aber das Ding unter Linux zum Laufen zu bringen war dann doch nicht so einfach wie gedacht.

Ich glaube, ich erwähnte es schon, aber LVM ist einfach cool. Ich bereue keinen Meter, schon seit 2002 LVM grundsätzlich auf jedem Linux-System das ich installiere einzusetzen. Damals war ich hauptsächlich scharf darauf, Festplattenpartitionen mit “sprechenden” Namen zu haben, die obendrein auch noch unabhängig davon sind, mit welcher Schnittstelle eine Platte an das System angebunden ist.

Aber auch Snapshots und die Möglichkeit zum Resize haben mir inzwischen schon öfter den Arsch gerettetdie Arbeit erleichtert.

Given a simple, switched LAN with Debian Linux (sid, iputils-ping) and Microsoft Windows XP (Service Pack 2, with the Windows Firewall disabled). A user complains about the network being slow (meaning his Windows notebook). I quickly find out that I can ping the box from my Linux notebook if my -s parameter is < 1393 or > 1472. If it’s between 1393 and 1472, no replies are received.

I spend the next hour with debugging this not so interesting phenomenon.

PlayingExperimenting with arping, I found the following behavior:

$ sudo arping -c 1 10.202.202.254
ARPING 10.202.202.254
60 bytes from 00:0f:20:d4:07:e0 (10.202.202.254): index=0 time=196.934 usec

--- 10.202.202.254 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered
$ sudo arping -c 1 10.101.2.1
ARPING 10.101.2.1
60 bytes from 00:0f:20:d4:07:e0 (10.101.2.1): index=0 time=168.085 usec

--- 10.101.2.1 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered
$

wtf? 10.101.2.1 is my default gateway (running a recent Linux 2.6 kernel), so it is ok to answer ARP requests. 10.202.202.254 is bound on the same box, but on a different interface, so I don’t think it is ok to answer ARP requests for that IP address on “my” interface, as it confuses some “what network segment am I on today” mechanisms.

Is there some /proc setting where I can disable this rather generous ARP behavior?

A few months ago, I have reported about getting the winmodem in my hp compaq nc 8000 to work.

Aside from the abysmally slow performance, the dependency on out-of-tree, non-free modules has been cause of grief since it has almost constantly forced me to keep an outdated kernel version around just in case that I would need the modem.

Fortunately, this is over now since more recent kernel versions (I suspect somewhere in the 2.6.16 era) support my winmodem natively without out-of-tree modules. All I need to get only on a POTS line is sl-modem-daemon, which is reasonably painless.

Letztes Wochenende war ich auf dem d.t.r.-Treffen in Röhrenspring im schönen Sauerland. Abgesehen davon, dass an dieser Location kein Mobilfunknetz verfügbar war, empfand ich das lange Wochenende als wunderschön.

Traditionell wird auf dtr-Parties ein Partylog geschrieben. Was ursprünglich ein Notebook mit offenem Editor war, ist inzwischen eine von Stefan geschriebene kleine PHP-Anwendung, die den Inhalt einer TEXTAREA direkt in ein Textfile schreibt - was einmal geschrieben ist, kann nicht mehr geändert werden.

Da Stefan diesmal erst später dazustößt, habe ich mir ein paar Gedanken gemacht und ein Notebook vorbereitet, das als Partylog dienen soll. Dabei hatte ich die Idee, aus dem Partylog ein Partyblog zu machen, und habe s9y eingesetzt.

Die Idee finde ich immer noch klasse, aber sie wurde nicht akzeptiert.

My notebook is an hp compaq nc8000 running Debian unstable, and I’d like to know whether it is “already” possible to use software suspend (hibernation). To my knowledge, there is a lot of different ways to do suspension, all of them differently broken and/or incompatible.

I’t like to run with an unpatched vanilla kernel, use suspend-to-ram and suspend-to-disk according to my choice at suspend time, and have the notebook wake up with the X session unhampered and the important hardware (sound, synaptics) still useable. Additional bonus points if wireless and/or wired network remains useable and USB/PCMCIA devices don’t need an unplug/plug cycle.

Which solutions should I investigate, which web pages should I read?

My notebook’s DHCP setup seems to be a challenge for DHCP servers around the world. Looks like almost no server implements the standard in a decently complete way.

My notebook has a wired Fast Ethernet, and a wireless 802.11bg network interface. Of course, both interfaces have their own MAC address. I want the thing to work at least at home, regardless of whether wired or wireless is in use, with preferably the same static IP address, and on the office wired network, again, with the static IP address allocated to me there.

Configuring this is considerably harder than I expected.

eine Produktreihe von DSL-Routern mit MIPS-Chip, die mit Montavista Linux ausgeliefert werden. OpenWRT ist für diese Hardware verfügbar.

Nun ist vor einigen Wochen ein User auf der netfilter-Mailingliste aufgeschlagen, dessen 504T nicht mit dem Linu-Rechner des Anwenders wollte: Außer ping hat nix funktioniert. Nun, diese Fehlermeldung ist nicht eben wirklich exakt, und deswegen enthalte ich mich eines Urteils, ob der User nun einen Fehler gemacht hat oder nicht.

Der Hammer ist allerdings die Reaktion von D-Link auf die Supportanfrage des Users. Sie besteht aus dem einzigen Satz “Der DSL-504T ist leider nicht kompatibel mit Linux”.

Das muss man sich mal auf der Zunge zergehen lassen: Da wird ein Stück Hardware ausgeliefert, das Linux als das eigene Betriebssystem verwendet. Und man hat es tatsächlich hinbekommen, dieses Linux mit einem anderen Linux inkompatbel zu machen und verkauft das dann auch noch als Feature. Bemerkenswert.