Attachmate Acquires Novell

On 22 november 2010 Attachmate annouced the acquire of Novell for 2.2 billion dollars. The planning to split the company in Novell and Suse with there excisting products.

What will this mean for us Novell guy’s? Read my previous post about this.

How to migrate from vSphere ESX to ESXi

Now that VMware has announced that vSphere ESX 4.1 will be the latest version that will be having a Service Console. They also annouced that customers who are running vSphere ESX should upgrade to vSphere ESXi in 8 to 12 months.

In this post I will discribe the (non-technical) procedure how to migrate. Non technical because I assume you guy’s will all probably know how to install ESXi, vCenter, create a cluster etc…

So how can we migrate to vSphere ESXi? Let us assume we have a vSphere ESX 4.0 with vCenter 4.0 enviroment who we want to migrate to vSphere ESXi. First step we have to take is to upgrade to vSphere ESXi 4.1 with vCenter 4.1. Where the upgrade to vCenter 4.1 is the first step.

As you all probably know, as off vCenter 4.1 you cannot install install this on a 32-bit operating system. So in case you’re running vCenter of a 32-bits Windows 2003 or Windows 2008 you’ll have to install a new (virtual) machine where you can install vCenter 4.1 on.  If you want to migrate the vCenter database to the new machine, check this KB article of VMware. If the information inside your database isn’t that much of a value you can install a clean copy of your vCenter.  Warming! When you are running Distributed Switches, it’s best to migrate temporarly to standard vSwitches and later on back to a Distributed Switch. This, because the configuration of a Distributed Switch is located on the vCenter host. The vSphere host only has the running part who cannot be modified without vCenter.
Make sure you keep you current vCenter server up and running so you can check the setting later for the new vCenter server.

Once you have installed  your brand new vCenter server, you can begin adding the existing vSphere host. For now we will add the vSphere hosts to the new vCenter server not being a member of a cluster. Why? High Availability (HA) makes use of a agent on the vSphere host. Later on, we will be reinstalling these host with ESXi. So adding them now to a cluster has no advantages.   If the time between adding the host to the new vCenter server and the reinstall of the hosts with ESXi is long, you can make the hosts member of a cluster, but I think that most upgrades won’t take that long.
When you add a host who is a member of another vCenter server, you will get a message like: “The host is already being managed by IP Address:……..”. This OK and you can proceed with the normal procedure.

Now that the hosts a member of the new vCenter server. It’s time to reinstall the hosts with vSphere ESXi. You can download your version of ESXi here.
When you reinstall the hosts with ESXi, make sure you know how the host is configured now before whipping the host completely. Think off:

  • Host name
  • IP Adresses (including default gateway, dns server, NTP etc)
  • Network configuration
  • Storage configuration

Finally after  reinstalling the vSphere ESXi host you can (re)create the new Cluster with all his features. If you didn’t delete you orginal vCenter server, you can check the setting from the original cluster for the recreation.

So there you have it. Now where ready (again:-)) for the future.

How to upgrade ESXi 4.0 to ESXi 4.1

I have done this a couple of times for my customers so I thought to document it for you.

In this senario I have 1 ESX1 4.0 host who I want to upgrade to ESX1 4.1. For this task I’m going to use the vihostupdate utility on the VMware Management Assistant (vMA).

First thing to do is to download the upgrade package (a zip file) form vmware.com. I guess you can find the package. Upload the file (upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip) to the vMA. Because I’m using my OpenSuse desktop I can use the scp command:

scp upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip vi-admin@10.1.0.2:~

If you don’t have Linux on your desktop you can use a tool like WinSCP to do the trick.

Notice that you have to use the user vi-admin because of security policies you cannot use root. When the file is uploaded login through ssh on the vMA (for Windows users you can use putty).

Before we can upgrade the ESX1 4.0 host we have to put the host in maintenance mode. I assume you all know how to do this. When the ESXi host is in maintenance mode, the first step we have to take is to upgrade esxupdate utility on the ESXi host.

vihostupdate –server [ip-adress] -i -b [path to upgrade zip file] -B ESXi410-GA-esxupdate

Note: The command is case sensitive!

Now we can upgrade the host.

vihostupdate –server [ip-adress] -i -b [path to upgrade zip file] -B ESXi410-GA

When the host is upgrade you can check the upgrade by entering the command:

vihostupdate –server [ip-adress] –query

If al is fine reboot the host and take it out of maintenance mode.

VMworld 2010 Copenhagen

Yes, I’m proudly to say that this will be the first time that I will attend VMworld 2010 in Copenhagen!

A couple of day’s ago I made my schedule and planned the evening events 🙂 for next week. I will try to blog every day about the session I will follow. The main interess is to follow the session about Cloud Computing. I think (and I’m not the only one) that vCD (VMware Cloud Director) will be one of the important products for VMware for the next few years. Of course I will follow session about VMware vSphere (especially the one about the road-maps) and VMware View. But the main focus will be Cloud Compunting.

apache2 could not bind to address 0.0.0.0:631 after vSphere upgrade

After the upgrade from vSphere 4.0x to vSphere 4.1 or ESXi 4 to ESXi4.1 apache on a OES 2 server wouldn’t start with the error

apache2 could not bind to address 0.0.0.0:631

As you all probably know TCP port 631 is for IPP print, or for us Novell guy’s iPrint. iPrint is started with apache (the website that is). But if iPrint cannot start, apache wouldn’t start also. So what’s blocking TCP port 631? The must be another service that’s using TCP port 631 for ipp printing. After some investigation I discovered that CUPS was started on the OES 2 server. And CUPS also uses ipp and so TCP port 631. So shutting down CUPS enabled me to start apache (rcapache start). Of course you have to make sure that CUPS isn’t started by default anymore on boot time (insserv -r /etc/init.d/cups).

But what started CUPS because it wasn’t started at boot time before. The only change that was made on the OES 2 was the upgrade of the VMware tools. So that was it.

I must say, not really nice of VMware to enable the start of daemons that weren’t started by default before? I don’t know what the reason is why they want to start CUPS for the VMware tools? So if you know the reason, let me know!