VMware Virtual Center – Physical or Virtual?

Over the yeas there have been some controversy over this topic. Should Virtual Center (vCenter) be physical or virtual? There is the argument that it should be physical to ensure consistent management of the virtual environment. Of course there is also the fact that Virtual Center requires a good amount of resources to handle the logging and performance information.

I’m a big proponent for virtualizing Virtual Center. With the hardware available today there is no reason not to. Even in large environments that really tax the Virtual Center server you can just throw more resources at it.

Read more of this post

Business Continuity and Disaster Recovery with Virtualization

In the previous years Business Continuity and Disaster Recovery have been big buzz words. All companies small and large vowed to launch initiatives to implement either or both in their current IT strategies. My question is what happened? Why is it that I rarely see organizations that have implemented or even have a plan to implement Disaster Recovery?

Is it a lack of understanding? Is it that most companies believe it is to expensive or complicated to implement? Well it doesn’t have to be either. Most companies that are undergoing virtualization initiatives already have half if not more of what they need to implement Disaster Recovery. The simple fact is if you already have at least two data centers and are virtualizing you are a prime candidate. Here are some common question and my answers regarding this subject:

Read more of this post

Network configuration for automated ESX deployment

I have been asked this question a few times so I thought it would be wise to post an article on it. When deploying an automated build script with the kickstart and/or installation files located on http, ftp, or nfs there are network configuration dependencies that you need to be aware of.

The ESX installer is a modified version of anaconda which is the same installer used for RedHat and a few or Linux variants. Anaconda is what allows for the kickstart portion of the automated build script. Anaconda itself has some limitations as far as what it supports.

Read more of this post

ESX local disk partitioning

I had a conversation with some colleagues of mine about ESX local disk partitioning and some interesting questions were raised.

How many are creating local vmfs storage on their ESX servers?
How many actually use that local vmfs storage?

Typically it is frowned upon to store vm’s on local vmfs because you loose the advances features of ESX such as vMotion, DRS, and HA. So if you don’t run vm’s from the local vmfs, then why create it? Creating this local datastore promotes it’s use just by being there. If you’re short on SAN space and need to deploy a vm and can’t wait for the SAN admins to present you more storage, what do you do? I’m sure more frequently than not you deploy to the local storage to fill the need for the vm. I’m also sure that those at least 20% of the time those vm’s continue to live there.

Read more of this post here

ESX vs. ESXi which is better?

So the question is which is better VMware ESX or VMware ESXi. A lot of die hard Linux fans will always say VMware ESX because of there attachment to the service console. The service is a great tool and once upon a time it served it’s purpose. Today there are many other options available to manage your VMware ESX servers without the service console. There is the Remote CLI, the VI ToolKit for Windows (powershell), and last but not least the VIMA.

With these tools you can effectively create scripts to help manage your VMware ESX environment without the service console. The service console opens up an additional security risks for each and every VMware ESX host you have deployed. Mitigating this risk increases the management overhead involved in the maintaining and deployment of these server in your environment. VMware ESX also consumes more server resources than VMware ESXi. The service console in VMware ESX uses CPU cycles and memory that you could be utilizing for virtual machines on VMware ESXi.

Read more of this post

Using the Ultimate Deployment Appliance to test ESX kickstart scripts – Part 2

In Part 2 of this series we are going to deploy our virtual ESX host in a VMware Workstation 6.5 virtual machine. We will utilize the UDA setup that we created in the first part to this series. If you haven’t setup your UDA you will want to do so before proceeding. Make sure you check out the sample deployment scripts available on our download page.

Watch the video tutorial here!

Using the Ultimate Deployment Appliance to test ESX kickstart scripts

In this series I am going to walk you through setting up the Ultimate Deployment Appliance (UDA) and VMware Workstation 6.5 to test Automated ESX Deployment Scripts (kickstart). The same principals that you will learn in this video also apply to using the UDA in a physical environment. The UDA is a very powerful appliance and I have found many uses for it. Using it as a medium to quickly and effectively test deployment scripts that I develop is just one.

Even in environments where the UDA is not allowed it can still be utilized. I regularly carry a 5 port gigabit switch which I can use to connect to my laptop to up to (4) servers to quickly deploy up to (4) ESX hosts at a time.

Click here to watch this video tutorial

Deploying Automted Kickstart Scripts Over HTTP

Originally I was going to cover all the various options for initiating your automated kickstart installation as “Automated Deployment of ESX Hosts Part IV”, but I have since decided to cover each method individually as there is a lot to cover and it makes more sense to break them out.

In this post I am going to cover deploying your servers over the network utilizing HTTP. To begin you will need a few things in place for this to work.  Below is a list of what you will need:

• Web Server to hosts the kickstart files and optionally your ESX installation.
• ESX Installation media or ISO’s for all versions of ESX you plan to deploy
• Your kickstart script

Read more of this post

VI Toolkit powershell simple script #4 – VM Information

This is a good powershell script for tacking virtual machine inforamtion for change management. It will output the vm’s name, the host it is on, the powerstate, Memory, Number of CPU’s, IP address, and FQDN to a csv file.


$IPprop = @{ Name = "IP Address"; Expression = { $_.Guest.IpAddress } }
$HostNameProp = @{ Name = "Hostname"; Expression = { $_.Guest.Hostname } }
Get-VM | select name, host, powerstate, MemoryMB, numCPU, $IPprop, $HostNameProp | export-csv c:\vm_info.csv

Read more of this post

VMware HA Cluster Sizing Considerations

To properly size a HA fail over cluster there are a few things that need to be determined.  You need to know how many hosts are going to be in your cluster, how many hosts you want to be able to fail (N+?), and it helps to know resource utilization information about your vm’s to gauge fluctuation.  Once we know this information we can use a simple formula to determine the maximum utilization for each host to maintain the appropriate DRS fail over level.

Here is an example:

Let’s say we have 5 hosts in a DRS cluster and we want to be able to fail (1) hosts (N+1).  We also want to have 10% overhead on each server to account for resource fluctuation.  First we need take 10% off the top of all (5) servers which leaves up with 90% utilizable resources on all hosts.  Next we need to account for the loss of (1) hosts.  In the event that a host is loss we need to distribute its load across the remaining (4) host.  To do this we need to divide up one hosts 90% possible resources by (4) remaining hosts.  This tells us that we need to distribute 22.5% of the servers load to each of the remaining hosts.

Read more of this post