VMs On The Edge

What started as a basic VM test has taken on a life of its own; it looks like we'll be walking the virtualization talk, pushing a VM host out near the edge of my production network. Wish me luck ...
I wear many hats. One of them involves the care and feeding of a campus network. My organization is in the midst of planning a summer upgrade to fiber, Internet2, etc., via a zippy connection to CEN. While there eventually will be much rejoicing, we're spending a bunch of time redesigning our edge components to make sure our world keeps working when we cut over from our current last-mile providers.

To keep things under control on our existing ~17 Mbps in and ~3.5 Mbps out lines, we rely on a Squid proxy running on a 2.6 distro of Debian and a homegrown Perl-based "Exiler" traffic-shaping tool running on top of BSD 4. Exiler sits transparently on our default route, while the Squid box is a sidestep off our core switch, annoyingly soaking up supervisor module CPU cycles under heavy traffic loads because of the loop-de-loop hops for cache misses. Damn you, iTunes U and your legitimate giant files.

So why am I writing about this in a virtualization blog? Stay with me.

1. We hope to incorporate Squid and Exiler in our new scheme, but we're facing a number of design and performance unknowns related to system resources under high bandwidth utilization, specifically NIC I/O for the shaper and disk I/O for the proxy. 1 Gbps is a bit denser than 17 Mbps, and both existing boxes are older, lightweight P4s.

2. We'd like to run both apps on the same box, but we don't want to deal with migration/rewrite issues for the different flavors of Linux.