vSphere: Move Hosts to New vCenter Server

I recently set out to recreate my vCenter installation since I was still running on Windows Server 2003 R2 64-bit and wanted to the set it up on Windows Server 2008 R2.  The problem here was that my Management Network was attached to a dvSwitch (Distributed Virtual Switch).  I’ll briefly outline the process of how I removed each host (3 hosts in total) from vCenter, attaching the host to the brand new vCenter installation with only about 10 minutes total virtual machine (VM) downtime.  This can actually be done with no downtime if planned properly and aware of the possible hiccups.

The new environment is now up and running, and after refining the process (poking around a lot), it only takes about 10 minutes to move each host.  This was done on vSphere 5 (moving from vSphere 5 to Update 1).

Advertisement

Using the Iomega IX4-200D as a Storage Target for vSphere (ESX and ESXi) Lessons Learned

I’ve been using an Iomega IX4-200D as a storage target for vSphere and have to say that for the most part it works well.  I’ve used it both as an iSCSI target and as NFS storage.

You can and should expect it to suffer typical storage performance issues.  It runs on 4 hard drives, mine in a RAID 5 array which is not the most performant, but best in case of disk failure and who wants to lose VMs.  It’s still a limited set of spindles to work with and keeping that in mind will save you troubles down the road.

At one point, I had 17 VMs running on a single IX4-200D.

Still interested?  Keep reading…

ESXi Going Forward, Is It Really All Doom and Gloom?

ESXi vs. ESX – warning, this is a rant! 🙂

I recently participated in a discussion thread on LinkedIn in the VMware Certified Professionals group that got to be a little lively.  In this discussion, outside of the original poster’s question, a side discussion began on ESXi vs. ESX and all the trouble that it entails.  One poster in particular, a former VMware TSE (tech support engineer), really preached doom and gloom about the product’s future with the announced phase out of ESX and transition and continuation of ESXi as the VMware flagship product.

I personally have mixed feelings about the decision.  I love ESX and have been working with the product for years now.  I like the accessibility and control that the service console provides and thus far have been willing to tolerate the overhead of the Console Operating System (COS) and some of the associated problems as a trade-off for the control that it provides.  Apparently there are people that are far more upset about this decision by the powers-that-be at VMware than I am though, and in one case the former TSE even said that he would look forward to seeing people ‘crumble’ when they have problems with ESXi and no console access.  As I’m running this blog, and try to provide information and help to people at their fingertips, I would never wish ill on my fellow techies or the organizations that employ them.  Well maybe a few… <grin>.

Use Console to Connect ESX to a NAS

UPDATED 12/5/2009 to include vSphere commands.

This is a quick note, mostly to help remind me and hopefully help someone else out.

You can use standard Linux commands to connect an ESX host to a NAS (Network Attached Storage) device.  You can use a NAS to store things like ISO’s and backups.  I have many gig’s of ISO’s and I really don’t like them taking up valuable storage on my ESX host.  In production, they’d be taking up SAN space, so I offload them to a Buffalo Terastation, and use Linux commands to mount the Terastation so that ESX can utilize it.

First you can make a directory under vmimages.

mkdir /vmimages/ISO2

ISO2 is the directory that you are creating.  For me, ISO already points to a local directory on my server where I keep one or two ISO’s that I am continually using.  Then you can run the command:

(ESX 3.5)  mount –t smbfs //[nas]/[folder] /vmimages/ISO2
(vSphere) mount –t cifs //[nas]/[folder] /vmimages/ISO2

Upgrading ESX 3.5 to vSphere 4 Using Host Update

Tonight I decided to go on the magical journey of upgrading my ESX 3.5 environment to vSphere using the Host Update Utility.  I’m usually a firm believer in ‘If it ain’t broke, don’t fix it!’ but this time I decided to take the plunge and see what happens.

A few months ago, I ran through the Host Update Utility and failed a hardware compatibility check.  I was running a few Intel Pro/100 NICs that ESX 3.5 was more than happy to work with but vSphere said, NO WAY.  After tracking down a few Broadcom 5701 NICs, installing them without a hiccup, I honestly still considered sticking with ESX 3.5, but after talking to a few friends who have had no trouble with their upgrades, I figured the most that I had to lose was a little time.  I ran through the wizard again, of the Host Update Utility, it complained about nothing this time and continued.

After a short while, maybe 10 minutes or so, I was up and running on vSphere 4.  No hiccups!  I immediately started booting up VMs.  I ran into my first problem. 🙂

Keep Reading…

Use Console to Connect ESX to a NAS

This is a quick note, mostly to help remind me and hopefully help someone else out.

You can use standard Linux commands to connect an ESX host to a NAS (Network Attached Storage) device.  You can use a NAS to store things like ISO’s and backups.  I have many gig’s of ISO’s and I really don’t like them taking up valuable storage on my ESX host.  In production, they’d be taking up SAN space, so I offload them to a Buffalo Terastation, and use Linux commands to mount the Terastation so that ESX can utilize it.

After logging into the ESX console using the root account or a root privileged account, you can make a directory under vmimages.

mkdir /vmimages/ISO2

ISO2 is the directory that you are creating.  For me, ISO already points to a local directory on my server where I keep one or two ISO’s that I am continually using.  Then you can run the command:

mount –t smbfs //[nas]/[folder] /vmimages/ISO2

SharePoint Virtualized = Excellent For Production

Though it goes against my better nature, as it is not like me to go against what some really big brains say, I’m tired of hearing from many people as well as ‘company lines’ that SharePoint and SQL Server are not good candidates for virtualization.  It’s easy to sell it that way, but it’s just not true.

The simulations and production deployments that I have been a part of speak otherwise, along with candidate architectures and testing that have been conducted by EMC.  As a matter of fact, I would say that SharePoint and SQL Server are excellent candidates for virtualization, as every production implementation should consider their COOP (Continuity of Operations) and DR (Disaster Recovery) scenarios as a major point of design.