I was sure you were linking to this xkcd:

It wasn't quite that bad, but it *did* wind up taking multiple months to figure out :-)

Next time you're wrestling with VMware, poke me.
I work there. :-)

I'll keep it in mind. In addition to hours of messing with config files, the unexpected incantation I needed was:

"ethtool -K eth2 sg off rx off tx off tso off".

I'm very, very lucky that Google is out there. I would never have thought of trying that. Ever. Probably not even if I knew about ethtool, which I didn't.

VMWare has really piss-poor online documentation on bridged networking if you're not already very familiar with it, which I'm not. Google, sadly, does *not* provide very good introductions to bridged networking in general. So I guess the lesson here is "bridged networking sucks unless you already know it well".

However, it's one of a number of things that works that way. Which makes for a bad VMWare experience if you're not a full-time sysadmin, which I'm really not :-)

Interesting, my vmware instances typically don't want anything to do with static ip addresses, and I'd open up the firewall ports individually if I did.

What were you doing that you wanted a static ip?

I'm running a Ruby on Rails server. I don't want to bother installing all the appropriate software versions on my main devel machine, and I want a deployment server that I can wipe clean easily. VMWare instance of Ubuntu Server, Rails install with only basic dependencies, no extraneous servers like DNS, DHCP, Apache, no devtools except the ones for debugging and deploying Rails. Hell, not even X-Windows or anything GUI flavored. I can keep my devel box behind the firewall so I don't need full "battle stations" security. I run the externally visible web and app server on the VMWare instance, which is carefully secured.

Better yet, Ruby and Rails stuff tend to be very happy running on a remote box. Most Rails stuff deploys via SVN or git (source-control tools), so synchronization isn't an issue. If I want to interact with my Rails app in a more user-friendly way (GUIs, helpfiles, visualizers) I can usually run the friendly part on my main dev box, often in a browser, and just point those tools at the IP address. I'm basically running my server stuff as if it were deployed at a colo facility at all times. It's just colocated elsewhere on the same hard drive :-)

And amusingly, when/if I start serious Windows/IE debugging, I can just put the VMWare image on an external disk, run VMWare from Windows, and basically debug in exactly the same way. The Ubuntu image will run in VMWare from either OS.

Like I say, virtualization promises a *lot* of good stuff to hobbyists, when and if it starts deploying painlessly. I'm really looking forward to more (and more capable) services like Heroku.

How do you keep your devel box behind the firewall and the vmware instance in front of the firewall if the vmware instance lives on the devel box?

I have two ethernet cards on the devel box. One, it actually uses. That one is hooked up to the firewall and wireless router. The other is configured with an internal IP address and no gateway so it's useless to the devel box, but the VMWare instance is bridged to it and configured to use it as a static address on the 'net at large. That's what took so long to set up.

Effectively, one network card belongs only to the VMWare instance, which you'd think would be a straightforward thing, but mainly isn't.