Sunday, March 29, 2009

VMware virtual networks sure are squeamish

I run a few heavy machines in VMs and have, for the most part, found it to be an excellent environment that practically guarantees isolation and provides administrators with a safety net that keeps them from ripping their hair out. But there are a few gotchas, and this one relates to bridged adapters.

Apparently, upgrading from VMware workstation 6.0 to 6.5 isn't guaranteed to work out of the box for Linux VMs. When the upgrade is complete, the Linux VMs fail to get IP addresses from the DHCP server. It turns out that a service called VMware Bridge Protocol that should be active on all physical Ethernet adapters, isn't working correctly. If it is removed and added manually, windows VMs get bridged just fine; but Linux VMs don't.

So, after a whole days of pulling my hair out, I figured I'd try rolling back the mess and guess what? Re-Installing workstation 6.0 gets the bridge protocol added automatically this time; but the linux vms were still off the wire! After wondering again, if it is the paravirtual kernel playing havoc with vmware's broken bridging protocol, I tried changing the network settings from being bridged, to manually using vmnet 0 and viola! The chatter on the wire is back on.

Of course, before selecting vmnet 0, I had to open the vmware virtual network editor and force it to not bridge automatically to a physical adapter, and then select vmnet 0 to use the Intel 10/100 ethernet adapter manually.

Yeah, this smells of some rotten fish; but hey, it sure beats running 15 physical servers eating away at the electricity and having to set up a freakish physical network to get em all running up to speed. I should begin looking into installing VMWare ESXi to isolate windows scruffles from these tailspins; but wonder if its worth it...

Sunday, March 22, 2009

Razer's Laws of software development

Basic truths and best practices for software development


1. There is no substitute for good development practices; no API in the world can make badly written code work well.

2. Write good software from the ground-up. Dependence on APIs that haven't been optimized will only result in fatter, slower code. The more there is focus on feature-addition on these APIs, the lesser inclined someone will be to go back and optimize them.

3. Focus on applying ONLY what is necessary to get the job done. There is no need to get a JIT, GC and a full runtime spooling up just to make a math calculation.

4. Focus on spreading complexity, not aggregating it. Modularity is your friend. Make it easy for someone to rip out what they think is inefficient and use a better module in your application.

5. Managers and users will never understand software development paradigms. Don't waste time forcing them to see your way. They see reliability, simplicity, cost and ease of use. Sell good software based on these factors.

6. Restrictions are your friend. Do not code apps that do everything at once. Users really want simple workflows. If your app has the features, but doesn't deliver the simple workflow; it won't be used.

Nuggets


1. What is simple, will scale well.
2. What is easy (to understand, to use), will be optimized more frequently by more people.
3. What is reliable will be used more often.