Legacy of Teaching

When I was a young and inexperienced IT guy I had a mentor who had a way of teaching me important lessons about the industry so that those lessons stuck with me through the years. One of the most important ones he taught me was how to leave your legacy as an IT professional wherever you go.

In a nutshell teach those who do not understand how the systems you are responsible for work and they in turn can assist you in acquiring goals you may not otherwise be able to attain. I’ve taken this lesson to heart. When I work with someone who is junior level to me I take it upon myself to develop them and mentor them as I was mentored. Its very much like a “pay it forward” model for IT. Just as I was mentored when I was starting out, so do I mentor those who are still young and without the battle scars from years of being in the trenches of information technology.

How this relates to VMware is fairly straight forward. If you pass on your knowledge of VMware to those you work with, they in turn will be better able to support the environment and assist those who may need help. Also, they can begin to serve as “ambassadors” of VMware to management and non-management which can come in very useful when you are attempting to prove the concept of a new VMware implementation. We all know some companies are resistant to changes. Therefore, anything you can do to increase understanding of a new system will benefit you. By taking the time to teach those around you about the VMware you widen the knowledge and acceptability of the platform.

One of the biggest challenges I faced starting out at the organization I am with now was gaining the trust in VMware from upper management. I started out small in the beginning. I got them to invest in VMware as just a development platform on which to host various non-essential test and development servers. Then, through a constant teaching of the solution and by opening up the environment so other could look around and not hurt anything and understanding of the technology began to spread through the department. I began to answer questions about the capabilities of the system and how things worked “under the hood” of the platform from others who were technical. They then began to talk about how great VMware is and what the potential of the platform was in terms of cost savings, scalability, disaster recovery, and server density. By others in my department discussing VMware as a solution in meetings they were in, they in turn assisted me in influencing upper management into using it for several low end production servers.

After this proof of concept was done and VMware had proven its mettle, other production servers began to be built or migrated into the environment. Now, we run several critical application and database servers in the environment because “HA gives us a type of clustering and failover capacity that we could not get in a standard single server platform.” Funny how my own words I used six months ago are now echoed back at me by management! I always nod and smile when I hear this.

During this entire time I’ve mentored a junior level administrator in the ways of VMware. The young “Padawan” (always throw in a good Star Wars reference if you can!) has learned well the ways of VMware and now can administer almost all aspects of the daily dealing of VMware to the extent that my time is now free to work on other projects. I’m now encouraging him to pursue his VCP to validate his knowledge of the platform. From this we have both gained. He is now a better tech and I have given back to the IT community. This has created a win - win situation for us both.

VMware and Baremetal Recoveries

Responding to a server hardware failure on a critical system can be one of the most stressful and difficult positions to be in as a systems engineer. I’m convinced that hardware failures have caused half of my hair loss (with my three kids contributing to the other half and the gray that’s creeping in what’s left!). So, what is to follow is how I’ve made this a much less stressful event for myself and my organization.

About two years ago we were at a quandary for backups. We are a TSM shop and TSM did not offer the baremetal recovery we were looking for and needed in our environment. If you are like us, you have critical systems running on old hardware that you are waiting to die on you. And, like me, you know that this hardware will die at the worst possible time for everyone associated with it. Hardware is mean like that and loves to give up the ghost at the most inappropriate times. So, to counteract this, we began a search for a baremetal solution that would serve our needs and make live easy on us.

Enter UltraBac. UltraBac is one of the best baremetal solutions for backing up servers I have ever seen. It integrates with TSM, has excellent customer support, and has saved IT bacon on multiple occasions. In the past year on three separate occasions we have used UltraBac to load a baremetal copy of a server on a VMware baseline server. Each time we have gotten the server up an running VMware in a 1/3 of the time it would normally have taken AND each time performance on the new virtual server for the failed server was deemed to be superior to what it had been on the physical server. One of those occasions we loaded involved a business critical SQL server that netted us a pat on the back for both improving performance and system reliability from the team that used the server.

What surprises me about this is that UltraBac seems to have a relatively small footprint in the market. For such an awesome product, this shocks me. Although, I can see this when I step back and take a look because there are multiple offerings for baremetal restore technology available.

So, if you are looking for a very nice baremetal solution, take a look at what UltraBac has to offer. We have certainly loved the product and continue to protect our systems with it.

Of VMware and NetApp

The organization that I work for uses Network Appliance as our storage vendor. Boy do we use it! To a tune of over 170 terabytes of storage! For our size organization I truly marvel at that number and wonder where it all goes.

That being said I truly believe Network Appliance to be the best storage vendor for SAN technology on the market. In one appliance you can get NAS, CIFS, iSCSI (they wrote the book on this protocol), Fiber, NFS, and a host of nifty tools and utilities you can work with. Also, their RAID protection protocol RAID-DP performs very well and offers advantages in terms of speed and reliability not found in other RAID typs.

So, what has caused me, as a VMware Engineer to love NetApp so much that I would sing its praises on a VMware blog? That can be answered in this way; Netapp allows me increased versatility and peace of mind in my VMware environment that I have been unable to find in any other SAN architecture.

One of the keys to this is a technology that NetApp has known as flexclone. With this technology I can take an immediate clone (or snapshot) of a system or LUN and then mount this flexclone on an existing system and it will be an exact point in time copy of the LUN that was cloned. This clone is merely comprised of pointers back to the original LUN and takes up virtually zero space starting out. This clone is also writeable and only the changes that are made take up space.

How can this help me you ask?

We have a scenario that requires us to have a DEV environment that needs rapid refreshes for its databases. Because our databases live on LUNs that are on the NetApp, we take advantage of this by creating flexclones of the database LUNs and mounting them on VMware servers which use iSCSI as the protocol to attach to the SAN. We have scripts that run on a schedule which creates these flexclones and mounts them on the servers in order to achieve the necessary refreshes. We do this with our DEV environments that require sporadic refreshes, TEST environments that require monthly refreshes, and BETA environments which use hourly refreshes in order to allow the developers to have access to current production data from our SQL environments. Also, should you want to make this flexclone permanent you can always split it from the parent LUN and the make it a standard LUN.

The great thing that we have found is that you can actually take a flexclone of a flexclone! This proves to be a wonderful concept when you want to test the changes you just made in the flexcloned DEV environment (cloned from production) but don’t want to risk making lasting changes at this stage or want the ability to revert back immediately in order to avoid lots of additional work. But that is just me “geeking out” at the moment.

Another area in which NetApp works very well with VMware is in the area of backup and recovery. In my environment I use RDM’s (raw disk maps) in order to mount SAN LUNs to the VM. Those RDM LUNs are where I place databases, programs, and other files that can change. I can then setup a snapshot cycle for those RDM’s for backup and recovery purposes. In the event of a problem that requires a restore, it usually takes me longer to type the restore command into the filer than it does for the filer to perform the restore! Its technology like this that allows me to sleep better at night AND serves the dual role of making me look REALLY cool when something bad happens.

NPIV Pitfalls

Recently, I was tasked with setting up NPIV in our VMware environment. While at first I thought this would be a breeze, I would soon learn that anytime I think something is going to be easy, I should think again.

My first challenge was, of course, the VMware upgrade. I had given myself the time over between Christmas and New Years to perform the upgrade as no one in my company seems to be around during that time. It’s much like a ghost town around here, just without the tumbleweeds. I had initially thought that the Virtual Center upgrade would be simple and the host OS upgrade would be difficult. It turned out to be completely opposite. However, the upgrade was performed successfully and with minimal hair loss on my part.

The next challenge I would face is coordinating the setup of the fiber switch to support NPIV. It was at that time I discovered that the IOS level of the fiber switch we use was not NPIV compatible. Since we had two new fiber switches with a current IOS level to support NPIV, we moved the VMware servers over to these. Of course I had to play Vmotion hop-scotch with my VM’s running on the host OS’s, but everything went well in this regard.

Now I was finally ready to get NPIV going. My path was clear and it was full steam ahead. I opened the configuration settings of my VM (which had the required RDM already) and setup my NPIV on it. I then went to our fiber switch admin and asked him to setup the zones. It was at this time that the path became blocked.. again.

Try as we might we couldn’t get it to see the new WWN generated by NPIV. And that’s when we made two discoveries. First, while NPIV was supported on those fiber switches, they had not bought the upgrade to have it enabled. Second, when the VMware servers were ordered (IBM 3950’s with 8 Dual Core Procs and 64 GB of RAM), the people doing the ordering had apparently ignored my request for 4Gb fiber HBA’s and instead ordered 2Gb HBA’s. And, sadly, 2Gb HBA’s do not support NPIV.

Ah, the frustration that can come with being in the information technology field.

So, here I sit with plan two. I’ve been given clearance to purchase the upgrade to the fiber switch. And as luck would have it we are going to be swapping out the VMware environment with newer models of the servers. Since I am completely in charge of this swap-out, the new servers will have the required 4Gb HBA’s.

Until that time we will be using NetApp’s snapdrive to connect through iSCSI to the necessary LUN’s. Since all of this was being done for convenience (in order to keep the scripts the same on the VM’s and the physical servers for attaching to LUN’s), I’m not to upset about it.

I just look at it as another journey down the road of IT and overall I learned a great deal about the entire process.

Adjusting the Default Timeout Used for Failure & Isolation Detection in HA

Have you ever thought that maybe you'd like to have more than 15 seconds before your HA begins to do its thing in VMware? I know I have. After doing a little digging I discovered how this is possible. What I found was that HA response time can be configured to different than the 15 seconds (15000 ms in VMware talk) normally given by performing the following steps:

1. Right click on the cluster->Edit Settings>VMware HA->Advanced Options
2. Add the das.failuredetectiontime = option/value pair to the cluster’s settingswhere represents the desired timeout value in milliseconds. For example, 60 seconds would equal 60000 milliseconds. You can do the math from there.
3. Next click the OK button and your configuration will be complete.

Now, VMware HA will not declare a host failure nor initiate an isolation detection response
until the timeout value specified has been exceeded without heartbeats received. This saves you, me, and the network team grief in the event of a network blip. Also, more importantly for me, it keeps me from pulling what little hair I have left out because due to a 20 second network problem I now have to wait 2 to 5 minutes for everything that was working just fine on the host server to come back up AND I have to explain why it happened to those in charge. Neither of theses are things I like to do.

“Host currently has no management network redundancy” Error Message After Upgrade

You have just completed upgrading to ESX 3.5 and Virtual Center 2.5 All is well and the final reboots are happening. Life is good in your world as “Lord of the VMware World”. Just as everything is looking fine, the yellow exclamation point appears on your server or cluster that has just rebooted. You click on it and discover an annoying and cryptic message:

“Host currently has no management network redundancy”

“Hmm… now what does this mean?” you wonder. Everything was just fine before in your virtual world.

Well, the answer is simple. ESX 3.5 and Virtual Center 2.5 likes redundancy in all things. You probably have done the exact same thing I did in my implementation; you only used one NIC for your management port. What’s happening is after the upgrade the Virtual Infrastructure has called thrown a yellow flag at you for not having enough NICs “in the box” (sorry, Bowl Season is in full force now and I’ve got football on the brain). Your Virtual Infrastructure wants you to have two NICs for the vSwitch the service console is on. Before you have another penalty called for unnecessary roughness (keeping with my football motif), understand that this is not a show stopper. It’s just VMware wanting you to follow best practices. Honestly, they are doing it for your own good.

My recommendation here is to add a second NIC to your port group that the Service Console lives on. Furthermore, I would dual home the network connections for these NICs and have each reside on a separate independent section of your network with each section living on its own power grid and having separate backup power supply. This serves the purpose of making VMware happy with you once again and giving you added redundancy on your service console. This redundancy will pay off in the following ways:

1. If you have only one NIC for the port group and this NIC should lose network connectivity you can no longer access this server to manage it until the problem is resolved. With two NICs enabled for the port group you minimize this risk and are only affected by a serious network issue.
2. Should you lose connection from your network to this single NIC (due to any of a host of reasons), your HA Isolation Response will not activate and turn the working servers off just to bring them back up on another server that it can detect. Again, risk is minimized for your virtual environment.

While having dual NICs for your service console port group may not be feasible for everyone, if you can I would definitely recommend it. After all, risk mitigation should be one of the areas we as IT technicians spend valuable brain power on. In my book risk that is avoided is potential work that is avoided freeing up our time for more valuable endeavors (like watching football!).

What I’ve Seen and Like About ESX 3.5 and Virtual Center 2.5

I recently upgraded my production environment to ESX 3.5 and Virtual Center 2.5. While on the surface things appear to be pretty much as they were, there are some differences that I especially like.

The first is the NPIV implementation. For those of you less than tech savvy that means N-Port ID Virtualization. In a nutshell, this allows the assigning of a virtual WWN (World Wide Name) to a virtual server which then allows a connection to a SAN through this WWN. NPIV essentially allows the virtualization of the fiber cards in the VMware Host server. While this may not sound that extraordinary, in our environment this is a real blessing, as now we only need one set of scripts for fiber as opposed to two sets for both fiber in our production environment and iSCSI in our TEST and DEV environments.

The next thing, while small, is still nice is the ability to resize .vmdk virtual disks from the Virtual Center Client. For me this takes the hassle out of having to log into the console and perform this upgrade. Anything that reduces my hassle I’m all for.

I also really like the Storage Vmotion Capability. This tool has already allowed me to consolidate wasted space on our SAN and upgrade two VMFS partitions to support larger files (yes, I actually have two VM’s that need over 500GB in storage!). This is well worth its weight in gold to me.

One other thing I’ve noticed is in Virtual Center 2.5. It seems to be a bit “peppier” and responds better for me. Mind you, I’m a bit annoyed that they didn’t provide me with a 64 Bit client. However, as a work around I installed the new Virtual Center client on our admin tools Citrix server and I now run the 2.5 client from there. So, it’s not really a big deal, just more of an annoyance. I’m sure when VMware looked at how many people actually use a 64 bit workstation for management purposes it wasn’t worth the time or the money in the initial release to provide this. From a purely business perspective I understand this. From a tech perspective I feel that they could have been more sensitive to the needs of we poor IT Techs.

I’m sure there are other features that I’m going to find in the new version and go “That is cool!” about. However, these are the features that provided an immediate impact for me. I wonder what others are thinking are cool features of the new ESX 3.5 and VC 2.5? Any comments on this?

How to Use the Remote Command-line Interface to Invoke Storage Vmotion in Windows Server or Desktop

Below are step by step instructions on how to perform a Storage Vmotion from a Windows system. After the instructions, I have also included an example for you to go by. I hope this helps to make the process a bit clearer for you. Any comments are always welcomed.

1. Download the Remote Command-line Interface from this location: http://www.vmware.com/download/download.do?downloadGroup=VI-RCLI. Be sure to put your email address and password for the VMware download site. If you do not have, please register and then login to download the software.
2. Double-click on the VMware-VIRemoteCLI-1.1.0-64644.exe to install the file. Choose the standard options and let the install take place.
3. Once this is done, open a command line (go to start > run and type cmd)
4. In the command line, navigate to the location of the VMware VI Remote CLI scripts. This is normally found at c:\program files\vmware\vmware vi remote CLI\bin.
5. Once in this directory at the command line to bring up the interactive session for Storage Vmotion., type in svmotion.pl –-interactive.
6. A command prompt will appear that states “Enter the VirtualCenter service url you wish to connect to (e.g. https://myvc.my corp.com/sdk, or just myvc.mycorp.com):”
7. Enter the url of your Virtual Center Server or your specific ESX server and hit enter.
8. Another prompt will ask you to “Enter your username:”
9. Enter your domain username used to access your virtual center server or the username used to access the specific ESX server and hit enter.
10. The next prompt states “Enter your password:”
11. Enter the password of your domain username used to access your virtual center or the password used to access the specific ESX server and hit enter.
12. The Remote CLI will then attempt to connect to the server. Once it is connect it will state “Connected to server.”
13. A prompt will appear and ask you to “Enter the name of the datacenter:”
14. Please enter the name of your datacenter after this prompt and hit enter.
15. Another prompt will appear and ask you to “Enter the datastore path of the virtual machine (e.g. [datastore1] myvm/myvm.vmx):”
16. At this prompt use the following format [datastorename] VM name/VM name.vmx and hit enter.
17. Another prompt will appear and ask you to “Enter the name of the destination datastore:”
18. After the prompt enter the name of the destination datastore. Do not place the brackets around the datastore name at this stage. Hit enter once you are complete.
19. A final prompt will state “You can also move disks independently of the virtual machine. If you want the disks to stay with the virtual machine, then skip this step.. "
20. After this, the prompt asks you “Would you like to individually place the disks (yes/no)?”
21. For a standard move choose No and hit enter.

The files for the VM will then be moved without taking the server down. Depending on the size of the files, this could take some time so please be patient.

Example of a Remote CLI Storage Vmotion

C:\Program Files\VMware\VMware VI Remote CLI\bin>svmotion.pl --interactive

Entering interactive mode. All other options and environment variables will be
ignored.

Enter the VirtualCenter service url you wish to connect to (e.g. https://myvc.my
corp.com/sdk, or just myvc.mycorp.com): myserver.testlab.com

Enter your username: vmuser

Enter your password: vmuser1

Attempting to connect to https://myserver.testlab.com/sdk.
Connected to server.

Enter the name of the datacenter: TestLab

Enter the datastore path of the virtual machine (e.g. [datastore1] myvm/myvm.vmx): [VMFS3] ITV99005/ITV99005.vmx

Enter the name of the destination datastore: VMFS4

You can also move disks independently of the virtual machine. If you want the disks to stay with the virtual machine, then skip this step..
Would you like to individually place the disks (yes/no)? no

Performing Storage VMotion.
0% ----------------------------------------------------------------------------
------------------------ 100%
#################################################################
Storage VMotion completed successfully.

Disconnecting.

Finally, after all of this, Dominic at VMProfessional.com has posted a script on his site that simplifies the process. Go here to get the script.

Thanks Dominic!

Hypervisor to the Rescue!

I recently asked my fifteen year old daughter what she thought hypervisor was. Her response was pretty funny.

“Is that one of your silly comic book characters, Dad?”

To that I laughed and said no, not exactly. However, the whole idea of hypervisor being a “superhero” got me to thinking (always a dangerous path for me). In a lot of ways in the eyes of many organizations and systems administrators, hypervisor has become something of a superhero. It’s minus the cape, bright spandex, and catch phrase, but a super hero never the less.

In the virtual superhero world there are actually two hypervisors. The first is the powerhouse superhero (much like Superman) of the two and is referred to as type 1. Type 1 boasts the power to be the “native” or “bare-metal” software that runs directly on a given hardware platform and along with many other powers has the ability to act as an operating system control program. It can do this all while residing underneath the operating system (OS) on the bare metal of the server hardware itself, which in itself is a powerful ability. VMware Virtual Infrastructure and XEN are just two of the “secret” identities that hypervisor type 1 goes by in normal society.

Type 2 hypervisor is the second of these superheroes. If type 1 is Superman, then type 2 is Batman. It doesn’t possess all the cool powers, but it does have some nifty gadgets in its “utility belt”. Type 2 lacks the nifty super ability to perform its duties underneath the OS, but still is able to get the job done of putting “rogue” servers in their place by running on top of a “host” OS such as Windows or Linux. In normal society type 2 hypervisor has several “secret” identities including VMware Server, VMware Workstation, Microsoft Virtual Server, and Microsoft Virtual Workstation.

Now you might ask how type 1 and type 2 hypervisors are super heroes. What do they possess that goes far beyond the realm of mortal programs and operating systems? The answer to this is simple. They both possess the ability to take one physical workstation or server and turn it into multiple workstations or servers. I run VMware Workstation 6.0 on my desktop at work. The desktop before VMware Workstation 6.0 is a 3.00 GHz, dual proc, dual core server with 5 gigabytes of RAM running Windows XP 64 Bit (yes, I haven’t upgraded to Vista… yet). With VMware Workstation 6.0 I also run four Windows 2003 R2 Standard Edition servers, two Windows XP workstations, and a Vista workstation. So, I have a total of eight separate systems running on my one workstation at the same time! Also, each of these virtual machines running my workstation is just a collection of files that can be copied and moved to other systems. Since they run “bare-metal”, or in normal terms, without the need to interact with the physical hardware of the workstation, (they instead relying on the hypervisor layer to supply them with RAM, Video Cards, Processors, Network Interface Cards (NIC), and all other hardware needed to run a system) these virtual machines can easily be ported to other workstations or servers of a completely different model, chip set, and vendor should the need arise.

How does all of this allow hypervisor to “serve(r) and protect” your friendly neighborhood systems administrator? For starters, once setup correctly, deploying a virtual server takes minutes instead of hours, saving the systems administrators time and energy and allowing he/she to focus more on other projects. Next, when properly thought out hypervisor will allow a disaster recovery plan to have all of the critical Unix, Linux, and Windows servers up and running within a matter of minutes at a disaster recovery site, potentially saving an organization millions of dollars and making the systems administrator appear to be a “superhero” in their own right. Another “serve and protect” feature is that the administration that goes with maintaining physical hardware in a datacenter is taken away by using hypervisor, be it as VMware, Xen, Virtual Iron, or Microsoft Virtual Server. If there are 10, 20, 30, or 60 servers residing on just one physical server then that leaves only one physical server for the systems administrator to maintain. Granted, that does leave just one point of failure for all those servers. However, most enterprise level hypervisor products allow and recommend an infrastructure of multiple servers to be setup in order to reduce the possibility of downtime. Some even automate the process of failover to existing servers in the event of a server failure. With proper design a virtual infrastructure has many of the same feature sets as a clustered environment and can allow for greater total uptime for the virtual servers deployed on them.

As Hypervisor (said in my best loud and commanding superhero voice) scans the horizon looking for organizations to rescue, a sense of peace and security pours through the hearts of systems administrators everywhere. Be it Type 1 or Type 2, both will assist the systems administrator in his daily routine and create a more flexible and stable environment for the organization he serves. With this peace and security organizations and systems administrators can sleep soundly at night knowing that hypervisor is on duty protecting them from the evils that lurk in the darkest corners of information technology.

Virtualization in IT: Where is it Going?

Five years ago virtualized architecture in an IT shop was “virtually” unheard of. Today, virtualization is the new buzzword. IT shops the world over are turning to virtualization to answer many of their needs for server consolidation, server density, power savings, and rapid deployment of server solutions.

In the past I’ve seen 20 virtual servers run on a blade with 4 gigabytes of RAM and 2 dual core processors. Whiles these virtual servers were only providing printing, DNS, WINS, and domain functionalities, the thought that they could all be run on one server that cost no more than $5K to this day amazes me. With virtualization today allowing for a more segmented approach to deploying applications, the days of bundling multiple server based applications on one server are quickly going the way of the Dodo bird.

So, where is this leading? What does the future hold for virtualization? Those are extremely good questions.

Since virtualization has already proven itself in the server arena, the next proving ground will naturally be the virtualization of the user’s desktops. This can already be evidenced by VMware’s VDI (Virtual Desktop Infrastructure) environment that leverages VMware’s ESX Virtual Enterprise environment to provide users with a virtual desktop that all their own. While centralizing the desktop environment of users has already been accomplished with products like Citrix, VDI serves to provide the user with a centralized virtual desktop that’s all their own and not “shared” with any other users.

This in turn will eventually go one step further with scaled down laptops that connect through the internet to a company’s server architecture and connect from anywhere to their virtual desktop. A move such as this would cut the costs of today’s laptops drastically by allowing for a scaled down version running a minimal configuration for hardware. A move such as this will make the days of important files being lost to hard drive crashes while hardening security for systems. When an employee termination is performed, a simple click of a mouse not only disables their account but also cuts access to their computer and any company information they had on the system.

Turning back to the server world, virtualization will only improve. With companies like VMware and XEN fighting it out over the next several years for market dominance innovations are sure to come quickly. Current problems such as how to quickly and efficiently backup virtual servers will quickly be solved (probably by borrowing from snapshot technologies like those employed by Network Appliance) and new features and functionality will begin to pour out with every code release.

All of this makes it easier on the guys in the trenches during all of this; the systems administrators. I have been told that one system administrator can realistically support 200 virtual servers by himself without significantly impacting his other responsibilities. While this may or may not be true, virtualization certainly does make a system administrator’s job easier by providing him with less hardware to support and an easy means of supporting and maintaining the virtual servers that are running.

In the last five years virtualization has come so far and integrated itself into information technology to a degree that IT shops would never consider going back to standard server deployments. One can only imagine where virtualization will five years from now.

Interesting Quirks I have found when setting up High Availability (HA) in VMware

While HA is a wonderful tool for giving servers in your virtual enterprise a “close to clustered” environment, the initial setup has proven to be a bit flaky. I have had to scratch my head in wonder at times when attempting to setup HA. Everything is done correctly, everything has been checked and rechecked, and when I finally begin the setup I get an error message telling me the setup has failed. At times like this I want to pull my hair out. However, since I really can't afford to do that (I sit in the express chair at the barber shop... the 12 hairs or less chair) I have been forced to rethink my strategies. Should you run into issues with HA not setting up on your servers correctly even though you know that you have done everything correctly, follow the below instructions.

1. Remove HA from the enterprise and then set it up again. Yes, this sounds hokey and silly, but it has worked for me in the past. Sometimes I think HA thinks of the first attempt as a trial run.
2. Should this not work, in Virtual Center right click on each Host server in your environment you wish to add to HA and select “Reconfigure for HA”. I have found in the past that this will resolve the issues after the initial setup of HA.
3. Should this not work, perform a reboot of the servers and attempt the two steps above again.

The last step is one I HATE to do in a production environment. Often, if you are running a large scale environment this means playing Vmotion leapfrog with all of the servers in your environment to accomplish the reboot.

So, You Deleted a VM and Now Want to Get IT Back.....

If you've done this (as I have in the past) you will need to reregister the existing Virtual Machine in VirtualCenter again. To do this, follow the steps below.

1. Select the ESX server in the VirtualCenter where the VM files are located.
2. On the summary tab right-click on the datastore where the VM files are located and click “Browse Datastore”.
3. Select the folder where the VM files are located.
4. Right-click on the VMX file for the VM and select “Add to Inventory".
5. Select a name and location for the VM and click Next.
6. Select the Host or Cluster for the VM and click Next.
7. Select a Resource Pool and click Next.
8. Click Finish and the VM will now reappear in VirtualCenter.