It was kind of my hope to get this off the ground in april.

I have two conflicting desires:

1) be able to do create a conference server as useful infrastructure for supporting this project, with things like irc support and other oddities. My requirements for this was native ipv6, a conference server, some sort of gui, no pots gw was required.

As the east coast would have the least latency overall, locating it there was highly desirable....

but then, there's:

2) be able to observe and fix problems at the ip layer with the new  bql/aqm stuff against voip and tcp traffic in the real world....

I'm a big believer eating our own dogfood; I intend to update all of our main servers to run linux 3.3 with sfqred enabled (after another month's worth of testing, I'm crazy, but not that crazy),

... but I was not big on the idea of adding a voip server to  huchra, or taking another piece of test gear (io.lab.bufferbloat.net) out of experimental and into a more production status, and in both cases, those boxes are located on the west coast.

I HAVE been able to coax asterisk and freeswitch to work on openwrt in the past but somehow I doubt it's suitable for a conference server... it would be interesting to try as a conventional switch, but... it's on a conference server that problems become most readily apparent.

 So at the moment, I'm thinking the best idea is to put up a test server on the west coast to meet desire 2, and work towards a way to apply desires 2 and 1 on the east coast, eventually.

In both cases I'm still kind of allergic to vms because that just eliminates a whole layer of control over the stack that we'd have if we  pursued and abused the latest kernel. I would certainly like to observe vm behavior, but not for 3-6 months longer, after the underlying OS can also be updated to 3.3....