VMWare ESX, virtualized DNS and an ISCI SAN

Since the fire we had last year we have replaced all our old servers with a new virtualized infrastructure. We're running VMware ESX 3.5, an HP BLc-3000 blade chassis with six blades, and an HP AiO1200R ISCSI SAN. It is working great and I have a writeup about that decision-making process that I will be publishing shortly.

Today I wanted to bring up one of the potential pitfalls when you're creating a fully virtualized environment. This past weekend we had to cut building power for an extended period of time, so the network administrator brought down everything in our server room. As he brought everything back online he realized that Virtual Center, the control console for VMware ESX, could not talk to the SAN because it required DNS resolution.

The Problem

Our DNS servers are virtualized with storage on the SAN. He ran into a chicken-and-egg situation where he had dependent services that relied on each other.

It took him a while to realize that DNS was the issue. The logs on the SAN side simply said "Could not connect ISCSI LUN". On the VMware side the virtual machines said "storage not available". Figuring out why the two were unable to connect took some careful analysis. Solving it proved difficult because our departmental wiki also used SAN storage, so he had no access to our documentation. In a flash he found himself back in the same situation he was in after the fire, when he could not access critical documentation because the servers with it were not available.

The Solution

So how did he solve it? Luckily he still had the old primary domain controller hanging out, which had all the DNS information. He was extremely lucky, and he knows it. To keep from having to rely on luck, how should you configure your VMware environment so this doesn't happen to you? There are a couple of ways to tackle it.

Use local storage for your virtualized name servers.

Pros

• Name servers will load without SAN access.
• Resilient to SAN outages.

Cons

• Cannot mix guest VM's that require SAN storage. The ISCSI initiator in VMware ESX loads when ESX boots. By having your DNS server on the same physical host as another VM that requires SAN storage, the guest on SAN storage will not be able to start.

Use a non-virtualized DNS server.

Pros

• Resilient to SAN outages.

Cons

• If using a Windows server, also requires you run Active Directory services.

Use hosts files.

Pros

• Resilient to SAN outages.
• May improve performance slightly since lookups will always be from local cache.

Cons

• Requires you add hosts files to the Virtual Center server, SAN server, and every ESX host server.
• Can be a maintenance burden if your environment changes frequently and you have to constantly add/remove ESX hosts.

We have opted for the last option. Our VMware host environment is fairly static, so maintaining hosts files will be a minimal maintenance issue. The resilience we gain from it make it very worthwhile. Oh, and we printed a copy of our wiki page that has all the hostnames and IP addresses of every server we have, and put it in the safe. :-) You do have a similar list, and a fireproof safe... right?

Installing VMWare Server 1.0.6 on Windows Vista Home Premium SP1 64-bit

First things first: I did not choose Vista. My boss bought a Gateway DX4710, which is a quad-core CPU with 6GB RAM, with the idea that we could install Windows Server 2003 on it. Unfortunately there are no drivers for Win2k3 and I'm stuck with Vista Home Premium.
Since we're without a test environment at the moment I decided to try installing VMWare Server 1.0.6 on it. Even though I can't add the Vista Home machine to our Active Directory network, I can add virtual machines. The host OS doesn't matter to me in the least, just the virtual environment.

Getting VMWare Server installed proved a challenge because Vista Home wants demands digitally signed drivers. VMWare doesn't come with those, so you have to disable the driver signing requirement. Vista also enables some TCP/IP options on the NIC that you have to disable in order to connect to the local VMWare host with the VMWare Server console.

Disabling driver signing

1. Press F8 after your BIOS POST screen to get to the Vista boot menu
2. Scroll down and select the Disable driver signing requirement option.
3. Log into Vista
4. Open a command prompt and enter the following commands:
   bcdedit /set nointegritychecks ON
   bcdedit -set loadoptions DDISABLE_INTEGRITY_CHECKS
5. Restart Vista

Updating the NIC settings

1. Start > Control Panel
2. Locate the Network and Internet entry and click the View network status and tasks link under it
3. Locate your NIC in the list and click View Status
4. Click Properties in the status dialog
5. Click the Configure button located at the top of the properties dialog, below the hardware listing
6. Click the Advanced tab
7. Change all the following to Disabled
   Flow Control
   IPv4 Checksum offload
   TCP Checksum offload (IPv4)
   UDP Checksum offload (IPv4)

Installing VMWare Server

A reasonable person may think that after changing these settings you should be good to go. Alas, you'd be wrong. You must go to the Vista boot menu and disable the driver signing requirement every time you reboot the computer. You will also get errors when installing VMWare server about the drivers being unsigned. If you click through the errors it will install the VMNet adapters just fine.

After you get VMWare Server installed and you launch the server console you need to select the Localhost option. If you don't see Localhost you either didn't boot Vista with the driver signing option disabled or you didn't change your NIC configuration.

Conclusion

After going through all this, I don't think we're going to use this system to run VMWare Server. It works... with a healthy dose of hacks and crazy workarounds. Heaven forbid the power goes out in the middle of the night. When the box comes back up VMWare can't automatically load any of the VM's since it will load with driver signing enforced, even though I have confirmed with a MS support person (who is a personal friend) that it should be disabled.

Using Vista has been incredibly painful. I understand things have to change, but options I have used for years no longer exist. Start > Run is gone. The Start menu is one long laundry list instead of a cascaded menu. I never found a way to get Explorer to show file extensions. There may be a way to turn some things on , but I find the OS too slow to bother learning.

This is an Intel Quad-Core with 6GB RAM running a 64-bit OS and a 7200 RPM SATA-2 drive. I shouldn't have to wait for it. Restarting takes between 2 and 3 minutes, opening the Network dialog hangs the computer for 2 - 3 minutes. Yes really for minutes, I timed it.

A word of warning about VMWare networking

When you configure VMWare Workstation you can set it up to use bridged networking. When you do this, VMWare creates a couple of virtual adapters it uses for communication:




These are assigned static IP addresses in separate networks in the 192.168.0.0 range. I'm not sure how it chooses which networks to use, but I'm guessing it looks at current established routes and picks something that won't interfere. Hopefully you can see where this is headed...

I ran into a problem where I couldn't connect to a server in 192.168.3.0. And you guessed it, it turned out that VMWare had assigned 192.168.3.1 to one of its virtual interfaces, which created route statements that redirected traffic. With VMWare becoming increasingly popular I wanted to point this out, just in case someone else notices strange results.