Felipe Alfaro Solana

And talking of the UNIX-HATERS Handbook and how outdated it is, I came across The Unix Hater’s Handbook, Reconsidered, digesting quickly through each chapter of the book and show nice counter arguments.

I’m still reading the UNIX-HATERS Handbook. I must confess it is very fun to read and it’s pretty obvious that it was written circa 1994 [1] because it contains some (currently) irrelevant comments like:

Unix was developed in a research environment where systems rarely stayed up for several days. It was not designed to stay up for weeks at a time, let alone continuously.

Now, from one of my OpenBSD firewalls:

fw1~$ uptime
 1:24AM  up 216 days, 23:07, 1 user, load averages: 0.21, 0.11, 0.09

And yet another OpenBSD firewall:

fw2~$ uptime
 1:30AM  up 216 days, 11:57, 1 user, load averages: 0.47, 0.21, 0.13
 

And actually this uptime does not impress me at all. I used to have a very old Pentium at home running EnGarde Linux that yield more than 300 days of uptime and could not beat the 1-year mark because of some power failure at home.

But the book has also some good points that have changed little (or didn’t change at all) over time. For example, the fact that in systems like he LISP machine the debugger is triggered automatically whenever a program misbehaves while, in UNIX, such thing never happens making debugging harder (files are closed, network sockets are torn down, etc.).

[1] There are some references to SparcStation ELC machines with 16MB of RAM in the book. Modern Intel Core i7 processors sport up to 12MB of L2 cache on-die, so you get an idea how old this computer (and the book) is.

libvirt and virt-manager are a blessing. They bring powerful, free, open source management to Xen- and KVM-based virtualization environments.

I’ve been using both for quite a while. Also, I’ve always prefered bridged networking support for my virtual machines over NAT. While NAT is non-disruptive and allows for isolation, I typically like to easily access services provided by my virtual machines, like SSH or NFSv4. Turns out that setting bridged networking support in libvirt is very easy, as long as bridged interface is detected by libvirt.

The simplest solution consists of creating a bridge interface that enslaves all the physical networks interfaces used to connect to the LAN or the Internet. For example, in Ubuntu, in order to enslave eth0 to a br0 bridge interface, while using DHCP for IPv4 address configuration, /etc/network/interfaces needs to look like this:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet manual

# The bridge
auto br0
iface br0 inet dhcp
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

Next time, when creating a new virtual machine, it will be possible to use bridged networking in addition to NAT-based networking. There is one caveat, at least in Ubuntu: libvirt and virt-manager by default connect to qemu:///user instead of qemu:///system. This is neither good nor bad by itself. qemu:///user allows a non-privileged user to create and use virtual machines and the process of creating and destroying the virtual network interfaces used by the virtual machines is done within the context of the user running virt-manager. Due to lack of root privileges, virtual machines are limited to QEMU’s usermode networking support. In order to use advanced networking feautures like bridged networking, make sure you connect to qemu:///system instead. That is typically achieved by running virt-manager as root (which is not necessarily nice). I tried playing with udev and device ownership and permission masks but it all boils down to the inability of a non-privileged user to use brcrl to enslave network interfaces to a bridge.