Yellow Bricks

by Duncan Epping

FT_HOSTS, where is it in ESX 3.5 U2?

· ·

This seems to be High Availability day! I was just testing my previous blog when I discovered a weird DNS or host file related error. So I opened up my console and typed “vi /etc/FT_HOSTS”. “vi” opened a blank file and reported back “new file”. What the heck, so I did a find and found that the FT_HOSTS file has been relocated to: /etc/opt/vmware/aam/. So if you’re looking for FT_HOSTS….

And for ESXi, you should be looking here “/var/run/vmware/aam/” by the way.

HA isolation response “shutdown guest”

· ·

So if you’re like me, better safe than sorry… than you’ve probably set your ESX 3.5 U2 HA cluster to “shutdown VM” instead of “Power off VM” or “Leave VM powered on”. By now most of you probably already noticed that when an isolation occurs HA will allow the VM to shutdown clean within 5 minutes. When the 5 minutes are past HA will shutdown the VM’s no matter what.

But for some of you 5 minutes(300 seconds) might just not be long enough, or if you have an ultra fast environment 5 minutes might just be to damn long….

So what can you do to shorten or extent… It’s easy, open up you HA cluster settings and click on advanced options and add the following:

das.isolationShutdownTimeout – values in seconds, default is 300

I’ve also updated my HA advanced settings blog! If anyone has more advanced settings that aren’t on the list let me know!

Response on the DABCC VMware HA vs Citrix HA article

· ·

I clearly don’t know much about Citrix version of HA, but I do know a thing or two about VMware’s version of HA.

The following are outtakes of the article over at DABCC:

VMware’s HA is heavily dependent on DNS or alternatively hosts entries being in place. The VMware implementation is based on the Legato Automated Availability Management (AAM), in fact some of us will recall that it used to place those logs into /opt/LGTOaam512/logs/ (since 3.5 this has been moved /opt/vmware/aam).

VMware’s HA uses the network to establish a heartbeat between all the ESX Hosts participating, So practically, what does this mean to the poor bloke who has to support the servers? If you network has a bit of a flap (personally I always blame the Network guysJ), your servers will implement an “isolation response”, the default server response will shut down your Virtual Machine to release the shared storage locks, this will allow the machine to be restarted on another host, this of course may not be desirable if the server is busy doing something, i.e. you may cause corruption or other issues with the Application/Database. In other words it won’t perform a clean shutdown. This is configurable such that you can keep the machines powered on, but this isn’t recommended in the case of NAS or iSCSI (as they are also network dependant) and you may end up with a split-brain situation.

There is now also experimental support for component level HA, i.e. if a Virtual Machine fails, then VMware will try to restart it.

  1. As of ESX 3.5 U2 High Availability doesn’t heavily lean on DNS anymore, it gets its hostname and ip info from VirtualCenter.
  2. ESX 3.5 U2 gives you the possibility to cleanly shutdown a VM in case of an isolation.
  3. Normally one would indeed provide it’s SC with redundancy, and preferably via two separate switches to avoid the problems you are describing.
  4. Virtual Machine High Availability isn’t experimental anymore as of ESX 3.5 U2.

Update on Kodiak

· ·

So I blogged about Kodiak a couple of days, and just received some new information. Let’s start of with the facts that weren’t clear in the first blog:

  1. Kodiak is not open-source at this time. (We’re working on that)
    We will be releasing an easy to use Open-SDK, and hope to eventually open up the entire code-base.
  2. Kodiak is 100% free for personal use.
  3. All systems purchased from bluebear include an unlimited use, enterprise license (and early code access).

Now, there’s already a discussion going on what “personal use” means.

But much more exciting in my opinion is the rumor that they’re polishing off a new feature – the
ability to manage multiple Virtual Center instances simultaneously and independently (as opposed to only ESX hosts at the moment)!!!

BlueBear will be opening the beta program to new registrants tomorrow, so better be quick! They will also be at VMworld in a few weeks (booth NI 10). And launch their latest product, for the enterprise; Grizzly!
In addition, all VMworld 2008 attendees will be given invites to Kodiak’s private beta!