North Star Labs

This is a bit less technical than my usual posts, but I’ve had the opportunity to test drive the closed beta of Grand Central, and I have to say… It’s features are quite incredible. In particular, I’ve lived without a land line phone for quite a few years now, and I have to admit; it’s been a real step backwards in terms of quality of service. The cell network just isn’t nearly as reliable as traditional copper has been.

Now, what I’m about to mention isn’t a huge leap forward in reliability, but it at least dramatically increases the chances of reaching me and holding a clear conversation. Grand Central is basically a phone de-multiplexer, giving you a new phone number and ringing all of your existing phone numbers simultaneously when it’s called. In addition, it works with Gizmo Project, similar to Skype, allowing you to receive incoming telephone calls on your computer. Toss in a cheap pair of ear bud headphones, and you’ve got yourself a decent alternative to a land line telephone and a much nicer sounding replacement to a cell phone.

Grand central has a lot of other features, like warm transferring calls between any of your extensions. I was able to transfer a live conversation from my MacBook over to my cell phone, over to my office line, and back to my MacBook, all without dropping the call. Visual voice mail, call recording, and much more make this a really convenient service.

This is just a record of a problem I ran into today. I’ve been working with two CentOS 5 Opteron servers connected to a shared SAN, and I’m using LVM tags to arbitrate activation of the correct volumes on the correct hosts.

While hacking at /etc/lvm/lvm.conf, I apparently forgot this file is copied into initial ram disk images in order to make a root device sitting on a LVM logical volume available to the kernel at boot.

I configured LVM to only activate devices with tags matching the host tags, which posed a problem when I upgraded to kernel 2.6.18-8.1.8.el5. At boot, the initial ram disk failed to activate any logical volumes because the tags were incorrect.

The solution was to make sure I specifically list the system volume group in lvm.conf, in addition to the host tags. For example, the following is correct:

tags { hosttags = 1 }
activation { volume_list = [ "@*", "VolGroup00" ] }

While the following configuration doesn’t activate any volumes:

tags { hosttags = 1 }
activation { volume_list = [ "@*" ] }

LVM Tags are a really nice feature. It allows me to control what logical volumes sitting on the shared SAN are activated by which of the hosts in the cluster. For example:

[root@xen02 ~]# lvdisplay @`uname -n` | grep /dev/
  LV Name                /dev/xensan/test01.rootfs
  LV Name                /dev/xensan/test01.swapfs
  LV Name                /dev/xensan/test-webserver 

[root@xen03 ~]# lvdisplay @`uname -n` | grep /dev/
  LV Name                /dev/xensan/dns1.swapfs
  LV Name                /dev/xensan/dns1.rootfs
  LV Name                /dev/xensan/newtest
  LV Name                /dev/xensan/ns1.vm
  LV Name                /dev/xensan/test2.vm

Shared block devices are nice; they facilitate live migration of guest domains between the two xen hosts.

I haven’t posted in awhile, but I was pleased with the results of this small hack. I booted VMWare Fusion on my Leopard workstation, and was disappointed that the keyboard doesn’t work on the console, so I couldn’t run ifconfig to look at it’s dhcp assigned IP address. I run vmware machines in NAT mode, so I couldn’t look at my dhcp server logs either.

The following shell script did the trick nicely. I went about my business, and eventually my computer spoke; “128 is up.” which allowed me to ssh in.

X=2
while [ $X -lt 255 ]
do
  ping -c 1 -t 1 172.16.90.$X 2>/dev/null >/dev/null && (echo $X: Up; say "$X is up") || echo $X: DOWN
  ((X++))
done

You may find this useful for locating machines if you don’t have nmap installed.