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.

Wenn eine Applikation über das Netz kommuniziert, funktioniert sie natürlich nur dann, wenn das Netz zwischen den beteiligten Maschinen diese Kommunikation auch durchleitet. Das ist im Internet üblicherweise der Fall; beim Übergang zwischen privaten Netzen und dem Internet in aller Regel nicht: Dort ist eine Firewall im Einsatz, die üblicherweise nach der Deny-all-Strategie alle Kommunikation blockiert, die nicht explizit freigegeben ist.

Auf diese Weise wird man im allgemeinen für eine neue Applikation eine Anpassung an der Firewall vornehmen müssen - es sei denn, die Applikation gibt sich Mühe, wie ein Dienst auszusehen, der üblicherweise freigegeben ist. Das tun zunehmend viele Applikationen und geben sich durch Benutzung von http als Transportprotokoll als Webclient und Webserver aus, was in vielen Firewalls direkt freigegeben ist. Doch dies ist Stoff für einen anderen Artikel.

In diesem Artikel möchte ich davon schreiben, wie die Spezifikation aussehen soll, damit der Firewalladmin auch weiß, was er für eine neue Applikation in seiner Firewall freischalten soll. In vielen Dokumentationen über (freie oder kommerzielle) Software findet man Listen von Ports, die mehr oder weniger vollständig und mehr oder weniger korrekt sind. Leider trifft in den meisten Fällen das "weniger" zu.

Four days before my wedding, I spent some time researching booting a PC from a large hard disk, where large means "larger than two Terabytes". These days, single disks are approaching this size, so we are near the state where this issue pops up for your run-of-the-mill computer rather than the data store RAID. Today, the per-gigabyte price is however still significantly cheaper if you go for a 1 T or an 1.5 T disk.

The old blog article shows that I spent considerable time in finding out today's limitations below the 2 T limit by using conventional partitioning schemes to boot a 2 T disk. Since I don't have this much storage available at the moment, I had to use virtualization and to take advantage of nearly empty virtual disks taking up much less space than their raw capacity suggests. This works fine as long as you don't start actually using the disk.

Back then, the only combination that worked for a raw disk larger than 2 T (only using the first 2 T) was Virtualbox and grub 0 (now grub-legacy). I regret to admit that the results of my experiments from June are not any more reproducible (most probably due to changes in Virtualbox since then) and that I was not able to boot any disk larger than 2 T any more, even if the partitions were well below the 2 T limit. I chose to ignore these results and to finally start the GPT research.

Steinar H. Gunderson, sesse, has written an interesting article about TCP performance. I didn't find your blog's comment function, so I am commenting with a trackback. (note: which didn't work either, "The auto-discovered trackback URI does not match our target URI")

I frequently use mobile internet, using various of the German GSM/UMTS network operators, out of a moving train. As you have written, this frequently causes packet loss which is not only not caused by congestion, but sends the congestion avoidance algorithms on a false path.

For example, when the train passes through the 3575 m long Distelrasentunnel between Frankfurt and Fulda, my network link is broken for like two minutes. Passing through other parts of Germany sometimes gives me a ping response of hundreds of thousands of microseconds by virtue of the rather huge send buffer the UMTS equipment has.

In these circumstances, ssh sessions frequently take tens of minutes to notice that the network is back before the session is useable again. Frequently, it doesn't come up again before an hour has passed. And I have not found a way to work myself around this. Can you explain what's happening here, and do you have any ideas to solve the issue?

Dear Lazyweb, sorry to bother you again, but I have tried to get this question answered on IRC, on Usenet and on the Samba Mailing List, and was not able to get an answer (not even a remotely clueless one) there. Can you help?

I currently have an "interesting" task to accomplish: An IT environment with about 90 % Windows and 10 % Linux machines would like to unify backup. Currently, the Windows world backs itself up to tape using Backup Exec; the Linux world has Amanda backing up to a big disk RAID.

This RAID is acting up and is scheduled to disappear. The current plan is to back up the Linux world with Amanda to a Samba share which is then backed up to tape by the Backup Exec installation running in the Windows world.

The Linux systems are in a diffent network, and the firewall people would like to keep the ports being open between the two networks to the bare minimum. I don't want to see NETBIOS Broadcasts inside the Linux world, I don't want to see this server in any network neighborhood, and the system acting as the Samba server for the backup should have as few open ports as possible. Of course, the share should be read only and to be as secure as possible.

Dear Lazyweb, can anybody with some advanced socat-foo tell me the command line needed to have socat create a socket in the local file system and to listen on it, so that I can have Virtualbox connect a virtual serial console to it?

The material available on socat on the web is sparse, and virtualbox-related docs usually contain "tick the create pipe option", which is not helpful here since I would like to see the first output the virtual machine prints to its serial port. It would be vastly more useful to have the socket already created with socat listening so that I can immediately see what is being printed to the socket.

Traditionally, the Linux kernel is software that I compile myself from pristine upstream sources for various reasons. I have three major kernel flavours that get built (server, desktop and notebook), and I am pretty current in running a bleeding edge kernel. This is not really necessary any more nowadays, but it's a tradition that works pretty well.

My kernels get built on sid and are packaged up with kernel-package, and equivs builds a dependency helper package which pulls in the kernel's dependencies such as initramfs-tools and takes care of cross-version updates like going from 2.6.29 to 2.6.30. Up to now, I was always able to run a kernel built this way on all my systems which can range from oldstable to unstable.

I have been using current KDE since most of my Linux time (having converted over from WindowMaker to KDE 2 back in 2002). But currently, I am seriously pondering to ditch KDE since KDE upstream seems to be wildly decided to kill KDE.

I have accidentally upgraded my desktop box to KDE4 because I missed putting KDE on hold before doing a major sid update after a couple of months. KDE4's first regression immediately showed itself - the right display doesn't get any attention from KDE. It just shows up in a grey checkerboard background, it doesn't have a panel, it doesn't have a menu, right click doesn't work. It looks like the only thing one can do with it is dragging windows onto it.

With help of #debian-kde, I quickly found out about this bug in Upstream Bugzilla, which is referred from #529487 and which was marked as Duplicate of this bug in upstream bugzilla, which is one and a half years old and was marked as "severity wishlist".

Despite the splendid job that the Debian KDE team has done to sort out the KDE4 mess, it looks like KDE upstream has managed to break Dual Head Setups for one and a half years and doesn't seem to be too interested in providing KDE4 in a way that it can be compared with past versions. This is very sad and will have me shopping for a new desktop environment soon, I am afraid.

Maybe it was not a so good idea to take away KDE 3 so soon and it might have been better to keep KDE 3 in Debian. Maybe it's time to re-introduce KDE 3 as co-installable packages? I would be willing to participate in this effort as a team member.

Which other Desktop Environments and/or Window Managers should I be shopping for? I'd like to have:

• Dual-Head support (preferably with the possibility to switch desktops only on one display, but that's something that even KDE 3 cannot do yet)
• Shortcuts like "gg:search words" or "wp:search words" to immediately open google, wikipedia, the BTS or the PTS
• Overlapping windows that are not automatically resized
• A terminal like konsole which allows me to have different session in tabs and to send my input to all tabs
• A clipboard handler that will automatically pop up a window asking me whether I want to open the URL that I just marked in a browser
• Integration with the Debian menu system
I will try adding to this list over the next days when I notice a feature that I have accustomed to so badly that I don't even notice any more when I'm using it.

Aus meiner Inbox bei $KUNDE:

ich sitze im Homeoffice und komme nicht ans Intranet....
Pinging intranet.example.com [62.157.140.133] with 32 bytes of data:

Reply from 62.157.140.133: bytes=32 time=66ms TTL=247
Reply from 62.157.140.133: bytes=32 time=68ms TTL=247
Reply from 62.157.140.133: bytes=32 time=71ms TTL=247
Reply from 62.157.140.133: bytes=32 time=68ms TTL=247