New article in Free Software Magazine

A new article of mine is on the home page of the Free Software Magazine. It is entitled "Firewall consistency with Firewall Builder". Enjoy!

Building a Xen firewall with Firewall Builder

Original post date: March 30th, 2011
Updated: April 4th, 2011 (missing rule in prolog)

It's a kind of a problem to manage a firewall for a Xen dom0 with firewall builder. Xen itself adds forwarding rules when starting a virtual machines, and these rules are wiped away when fwbuilder scripts install theirs, which is unfortunate.

Summing up everything, the final plan was to install a firewall on dom0, which should a) forward to the VM the packets originating outside and directed to them (and back), and b) protect the dom0 itself.

It took me some time, experiments and advice to get it right, and here's how. … Continue reading

Restoring Xen’s iptables rules

Those of you that use Xen may have noticed that, by default, Xen adds some iptables rules when a VM starts, so to ensure that some specific packets are actually forwarded to the virtual machines. If, for any reason, those rules are wiped away, it would be nice to recover them, wouldn't it?

I found out it's quite easy. The following script will just echo the iptables commands so you can safely test it on a running dom0. If it does something that you actually need, just wipe those echo's away!

#!/bin/bash

xm list | perl -alne 'next if not $F[1] > 0 ; print "@F[0,1]"' | while read VM ID 
do
  xm network-list $ID | perl -alne 'next if not $F[0] =~ m{^d+$} ; print $F[0]' | while read IFID
  do
    VIF="vif$ID.$IFID"
    echo iptables -A FORWARD -m physdev --physdev-in $VIF -s $VM -j ACCEPT
    echo iptables -A FORWARD -m physdev --physdev-in $VIF -p udp --sport bootpc --dport bootps -j ACCEPT
  done
done

I am using Perl here because I know it better than awk, but I am sure that awk can accomplish the same task as well as perl does.

independent_wallclock in Xen 4

I was asked to set up clock synchronization for a Xen VM, running on top of Xen 4.0, which in turn was running on top of a Debian Squeeze. As you may know, NTP on VMs just sucks, so I was looking for Xen 3.0's independent_wallclock setting, and have domU's clock follow dom0's.

With my surprise, /proc/sys/xen/independent_wallclock wasn't there anymore.

With some surprise (but not as much), my searches in Google returned just crap.

As it often happens, IRC came to the rescue. Or, well: no rescue, but at least I was provided with a reason:

(15:51:10) The topic for ##xen is: Xen 4.0 http://www.xen.org/downloads | XCP http://blog.xen.org/index.php/2010/11/24/the-xen-cloud-platform-xcp-1-0-beta-is-available-from-xen-org/ | Wiki: http://wiki.xen.org/ | Solaris: http://www.opensolaris.org/os/community/xen/ | Logs: http://zentific.com/irclogs | Management: check out #zentific
(15:54:48) bronto@freenode: hello! It's maybe an FAQ, but I couldn't find an answer anywhere. Xen 4.0 doesn't have /proc/sys/xen/independent_wallclock (at least, not in Debian Squeeze Linux). Is there any equivalent?
(15:55:14) bronto@freenode: I would like domUs to follow dom0's clock, and sync dom0 using NTP.
(15:55:42) pasik: bronto: it depends on the kernel
(15:55:47) pasik: bronto: pvops kernels don't have it
(15:55:57) pasik: bronto: old xenlinux kernels do have it
(15:56:33) bronto@freenode: pasik: thanks. hmmm… so, the solution is: use a different kernel?
(15:56:40) pasik: bronto: or ntp
(15:56:55) bronto@freenode: pasik: NTP on domU's? Uh, that just sucks…
(15:58:57) pasik: bronto: pvops (upstream) kernels don't have independent_wallclock because there was some problems with it, it wasn't thought to be accepted to upstream Linux
(15:59:03) pasik: bronto: I can't remember the details now
(15:59:27) bronto@freenode: pasik: ouch… 😦
(15:59:41) bronto@freenode: pasik: this is damn bad
(16:00:31) bronto@freenode: pasik: OK. I'll fall back to ntp, and hope it will work

Debugging NTP again (part 4 and last)

I finally got the Xen servers' clock to stabilize! The clocks kept converging overnight, and are now sporting a very little offset -so little that the graph for today have visible hiccups.

The problem appears to be caused by a kernel bug. If it was fixed in more recent kernels and/or patches, I just don't know. Anyway, the kernel bug is worked around if you set disable kernel in your ntp.conf. Besides, you should set xen.independent_wallclock to zero, and set your clocksource to xen.

Sure, it would not have been possible with the help of other people, so let's tell the full story and provide acknowledgements for those who deserve it. … Continue reading

Debugging NTP again (part 2)

If you wonder what I tried yesterday, well here you are. I tried to make one of the two crazy servers a unicast client. I hoped that having the chance to decide when to poll the stratum 1's would help them to adjust better. Although a bit "irregular", it seemed to work better for a while. Unfortunately, when I came back to the office today and looked at the graphs, it eventually started to oscillate more and more during the night, until it had a reset today. The other one is still going bad, of course.

One more day has passed, and still looking for a solution… … Continue reading

Debugging NTP again (part 1)

Xen servers are well known for having time synchronization problems. I have a few here, too. Two datacenters, with three multicast NTP servers and two Xen servers in each. And in each datacenter, one of the Xen servers is working like a charm, while the other's offset keeps oscillating more and more, until ntpd resets, and the cycle starts again. Using known workarounds just made things worse.

Having a Xen servers's clock suddenly going backwards from time to time isn't any good. This really calls for a deep debug. … Continue reading