I mentioned previously that I’m a big fan of virtualization and all the attendant advantages that come with it. For many tasks, speed is less relevant than flexibility, and virtualization of operating systems gives flexibility to you in spades. You can split functional server roles across different images very quickly instead of mixing them on hardware because of limited machines. You can migrate images very quickly to any hardware configuration. You can mix and match virtual machines on new and old hardware. You can clone and duplicate images extremely quickly. The list goes on and on.

I spent much of the past week setting up a virtual network consisting of Windows Server 2003 and SQL Server 2000 inside VMWare Server. The idea was to completely test the deployment scenarios for data loads and replication in this virtual network without having to buy five or six separate machines. Great in theory, but would it work in practice?

Well, just for my own edification, I decided to do this the hard way. 64-bit SUSE Linux 10.1 with VMWare on top of it. “I know Windows well enough, why not try something different?”, I say to myself.

Long story short, it seemed to be working…at least for a while. I spent some time documenting the process of setting up the server roles in the network. But eventually, during the data load process, I find myself constantly running into these inexplicable SQL Server errors…”database consistency” errors, nodes that were in one place but were supposed to be in another, and “NOLOCK” errors failing due to data movement, despite the fact I wasn’t using the NOLOCK keyword and nobody else should have been changing data on the virtual machine anyway. Errors you basically should never see. Worse, they seemed random…sometimes the same data would work during a load and subsequent processing, sometimes it wouldn’t. Small random errors are ugliest types of errors…at least when something blows up big, you can tell what’s wrong.

Who knew what the problem was? Bad hardware? Bad host OS? Bad virtualization? To me, it was completely unfathomable that a virtualization product, especially a server class product like, could simply not be working correctly. So I switched over to hosting under Windows Server 2003. Then I moved over to a box with all Intel hardware. Then I went native. Native seemed to work. But I really had no way to completely verify unless I built up the whole network, and I needed a virtualization product for that…I wasn’t going to be digging up 4 or 5 new machines tomorrow. I also wasn’t looking forward to having to learn a whole new product and rebuild the network yet AGAIN on top of that.

Anyway, sometimes you have to do things you don’t like. On Friday, I decided to bite the bullet. We went to Fry’s and bought a 500GB hard drive so I would have enough room to build more images. Then I spent parts of the weekend and this Monday rebuilding the network from scratch. Luckily, this wasn’t too hard to do since I had already documented everything. The worst part of it was having to learn how Virtual Server 2005 does its virtual machine management and figuring out how to set up the machines inside behind a virtual NAT. The process isn’t straight forward at all and involves installing a special Microsoft Loopback Adapter driver. Still, I’ve hacked my way around setting up NAT’s and RRAS so I muddled my way through somewhat competently.

Virtual Server 2005 is a free product.  It’s somewhat odd that Microsoft is releasing it for free…sometimes you wonder if MS is trying to “Netscape” VMware.  At any rate, the product, for some reason, is managed entirely via a web interface.  Decent in theory, but VMWare’s native client management works much better overall, I find, and still has the web management if you need it.

Managing the virtual machines remotely via Virtual Server 2005 was very slow, even with reduced color support enabled. The remote control protocol in use seems to be based on a version of VNC, but they don’t have the grayscale options that VNC does.

I also accidentally set the NAT up on the wrong adapter, so I had to come into the office to fix it because it completely killed the network connection of the box hosting all the virtual machines.

Well, I finally did get the network set up. I’m happy to report that SQL Server is in fact stable inside Virtual Server 2005. On the one hand, I’m relieved I have something I can actually trust to work correctly in terms of getting my current work done. On the other hand, I’m greatly disturbed that VMWare has such a serious bug in its virtualization product. I plan on using virtualization extensively moving forward so that I can stay exposed to all the different operating systems out there, and VMWare was definitely going to be my first choice. (note to self…next laptop needs lots of RAM and HD space)

But after this? Yikes…a little scary. It’s kind of like believing in Santa Claus for a few years and then finding out he doesn’t actually exist. (Sorry if I spoiled that for anyone.) Still, I’m going to be keeping an eye on VMWare. I find that in overall usability terms, it’s a far better product, and this is the first time I’ve encountered a bug like this. I also find the idea of having to virtualize with Windows as the host OS somewhat counter intuitive.

Running Virtual Server 2005 isn’t all roses either.  Installing the Loopback Adapter has somehow snookered FTP on the system…I suspect it has something to do with the RRAS NAT I configured on the system, which is timing out the control connection on PASV FTP transfers.  Basically, long FTP’s die at the end of the transfer.  And then there’s whole deal with Windows taking years to shutdown now.  And by years I mean minutes…but it seems like an eternity.  Does it ever end? =P