Malaysia VMware Communities » ESX

Upgrade from ESX 4 to ESX 4 update 1 with update manager fail

craig — Thu, 26 Nov 2009 05:26:06 +0000

Just found the note from VMware today about the possibility of upgrade fail if you are trying to update you ESX 4 to update 1 with update manager.

When attempting to upgrade ESX 4.0 to ESX 4.0 Update 1, you may experience the following symptoms:

Update Manager (VUM) upgrade operation fails or times out at 33%.
Upon reboot, the host that was being upgraded displays a purple diagnostic screen with the following error:COS Panic: Int3 @ mp_register_ioapi

Who is affected

Customers using VMware vSphere 4 upgrading to Update 1 with 3^rd party management agents running.

Solution

To avoid this issue, prior to the update, disable all 3rd party management agents running on the ESX 4.0.0 server before applying the update.

Note: The 3rd party management agents can be enabled after the upgrade is completed.

If you have already updated the ESX host, do not reboot the ESX host. Open a support request with VMware support.

WARNING: Rebooting the host means the host has to be reinstalled because it is not recoverable after a reboot.

WARNING: If you have virtual machines running on local storage, they may not be retained if you reinstall ESX 4.0 as a result of this issue. Contact VMware Support for assistance in recovering those virtual machines.

The full KB can be found here

Tags: ESX, Update Manager, VMware

Apply VMware vSphere 4 Update 1 Patches

Jas — Wed, 25 Nov 2009 06:12:36 +0000

VMware ESX 4.0 Update 1(Build 208167) was released on 19 Nov 2009 and I did a patch update on 3 of my vSphere Dev Servers included of 1 ESX (build 164009) server and 2 ESXi (build 164009 & 171294) servers on Dell PE2950 today.

The Redhat Linux and Windows 2003 & 2008 Virtual Machines VMware tools upgraded successful and everything look goods after the Update 1 patched.

I would suggest you refer to VMware Communities – vSphere Upgrade and Install forum & “vSphere 4u1 – any issues” thread before apply any VMware vSphere ESX/ESXi Update 1 patches on production environment.

Read more details about VMware ESX 4.0 Update 1 Release Notes here.

Updated:
Please make sure you check VMware Knowledge Base – Upgrading ESX 4.0 to 4.0 U1 using Update Manager fails or times out and rebooting the host results in a purple diagnostic screen
A quick note: The problem with U1 is now known to be limited to HP Proliant systems and HP Insight Management agents are running.

Tags: ESX, Patch, Patches, release, update, upgrade, VMware, vSphere

ESX Cluster through WAN with Netapp Metro Cluster

craig — Tue, 17 Nov 2009 16:40:20 +0000

Recently there are some request from my client who suggested to have their production and DR site to be automated protected and fail over in the event of disaster. VMware SRM seems to be right choice for most of the time, but these clients are decided to bring it to another level of fail over procedure during the DR happen. I am doing some research today and found this interesting topic from Netapp which the Metro cluster suppose to synchronize from production to DR through dark fiber to prevent controller failure, DR or disk corruption.

If the bandwidth is not a concern in this case, ESX HA cluster through both data center is workable with Netapp metro cluster. In the event of disaster happen, the VM should be restarted as the normal HA kick in from the ESX cluster.

you can read more information from the link here.

Tags: ESX, Netapp Metrocluster, SRM, VMware

VCenter Installation Error 28038

Jas — Tue, 03 Nov 2009 08:06:04 +0000

I’m getting an “error message: 28038″ just before the VMware VCenter Server installation end as screen shot below:

Workaround:

It’s pretty simple but it took me few hours(damn!). Please make sure your VCenter server have minimum one network cable connect to switches.

Tags: error, ESX, Installation, vCenter, VMware, Windows 2008

NetApp Virtual Storage Console (VSC) for ESX ready for Download

craig — Tue, 27 Oct 2009 14:06:40 +0000

Netapp had official release the virtual storage console for VMware ESX host. You can view more information from here.

If you are netapp existing customers, you can download the software from here

Below is the summary I link from Netapp official blog site

Summary of supported functionality in the 1.0 release includes:

Support for ESX 4.0 and ESXi 4.0 hosts.
Limited support for ESX 3.5 and ESXi 3.5 hosts (listed and details provided, but setting not set – requires using EHU for host settings)
Viewing the status of storage controllers from a SAN (FC, iSCSI) perspective.
Viewing the status of storage controllers from a NAS (NFS) perspective.
Viewing the status of ESX hosts, including ESX version and overall status.
Checking at a glance whether the following are configured correctly, and if not, automatically setting the correct values without needing to access the ESX console. You can select multiple ESX hosts and update settings for all hosts with a single command.
Storage adapter timeouts
Multipathing settings
NFS settings
Collecting diagnostic information from the ESX hosts, storage controllers, and Fibre Channel switches.
Tools to identify and correct misaligned disk partitions (MBR Tools)
Tools to set proper guest operating system disk timeout values

Tags: ESX, Netapp, Virtual Storage Console, VMware

SRM 4 is ready for VMware vSphere 4

craig — Mon, 05 Oct 2009 08:42:01 +0000

SRM version 4 had officially released and ready to download from VMware Official Website. Before this, users with SRM will not able to upgrade to vSphere 4 due to the SRM compatible. Now you will be excited to upgrade your existing ESX 3.5 to vSphere 4 with SRM 4. You can read more about SRM 4 from here. You can download the latest copy of SRM 4 from here.

Tags: ESX, SRM, VMware, vsphere 4

mgmt-vmware service malfunction

craig — Wed, 08 Jul 2009 07:46:55 +0000

Most of us may had previously experienced a VM which hung in the ESX hosts. Usually we will use the command vmware-cmd utilities to kill or stop the virtual machine. Sometimes we even need to use the vm-support command to force the VM to be stop hardly if vmware-cmd was not worked. Today I found some interesting issue with 1 of the virtual machine. I had executed the instruction to power off from vCenter 4. This virtual machine is running on vsphere 4. After 2 minutes, the virtual machine still showed power on from the vCenter, and I executed again the 2nd command to power off, the system prompted that another process was in progress, and access was denied.

It looked like the virtual machine was hung, and I started to check the virtual machine status from ESX console. I could not find my virtual machine was still running at the time I checked from the command prompt. Some guys may already got panic and restarted the ESX host, but I decided to take a last try and restarted the mgmt-vmware service from /etc/init.d , guess what, it works after that. The vCenter now show the virtual machine had been power off. The inconsistent information of vCenter always cause some issue to the day to day operation. Hope this tip will help the 1 who run to the same situation as I did.

Tags: ESX, vCenter, VM, vSphere

Not possible to resize /var/log on vSphere 4 Host

craig — Wed, 01 Jul 2009 11:43:28 +0000

As my previous experienced, if you having a disk space full on /var, the host server will getting an error message such as “A general error occured : Failed to create journal File provider” when creating a new virtual machine. I had my test machine setup as default configuration, which the /var/log only allocated for 2GB in place. Prior to move the system to production, I decide to extend the /var/log from 2GB to 10GB as our current standard. Here come to the idea that I try to extend, unmount and remount as I usually did on the Linux.

I found that the partition table for vSphere 4 is totally different as ESX 3.5 did. At 1st was confusing as I only have 1 logical drive with RAID 1 configuration on my vSphere 4 machine, but when I did the cat /proc/partitions, it showed as 2 physical devices as sda and sdb.

I tested to delete the partition table from the fdisk utility as I did on usual Linux, but is not success. The system will roll back to the existing partition table before I tried to make the changes automatically. You may see the IO error happen when you try to write the partition table. At the same time, I found that there is a vmdk with similar 8GB of flat file and vmdk was created on the existing datastore which reflect the local storage on the vSphere host. It is viewable through CLI and vCenter client both. After some research, looks like the virtual disk is referring to vSphere core module and important mount point such as / & /var/log. Whenever I tried to remove the virtual disk from the ESX host, I get denied with error message of the virtual disk in use.

This 2 screen shots had helped me to understand that the new system partition method in vSphere 4, which is totally different as it did in ESX 3.5. At the mean time, I also found that to format the rest of the unclaim partiton on the local HDD for VMFS 3 file system as Datastore is compulsory during the setup too. Therefore, sizing on the partitions require to be planned prior to final deployment.

Tags: Disk, ESX, host, var, VMFS, vSphere

Virtualization on Blade

craig — Sun, 28 Jun 2009 16:50:20 +0000

We see the growth in the market to be more aggressive for consolidation in the data center for both physical and virtual server from time to time. There are plenty of solutions in place allow blade to support virtualization today such as virtual connect from HP, pass through module, infiniband integration Xsigo, Cisco UCS and etc. This had significant resolved the I/O interfaces require per blade to host the virtualization host server. CPU and memory per blade and significant increase with the latest release from all the major server vendors, the CPU, memory and disk I/O are no longer the concerns for virutalization.

But I do want to point out some of weakness on the solutions proposed by the deployment team or vendors that suggest to start with 1 blade chassis to reduce the CAPEX require. To achieve the fully redundancy on the virtualization, we may require NIC teaming, redundant FC connection, redundant ISCSI HBA and etc. Some of the guys may had forgotten about the chassis issues on the blade today. If I would like to run the virtualization hosts or clustering servers on blade, I will not choose to go with only single blade chassis in this case. I will not believe there is 100 % guarantee of no failure on the chassis of the blade. I will definitely suggest to split the blade across to 2 different chassis as minimum to minimize the risk. But of course, we may still have a single point of failure on the SAN which require huge amount of capex investment to keep the production storage to be redundant. Imagine if you run 5 ESX hosts on single blade chassis today, you will easily achieve 15:1 per blade for consolidation, and if you are UNLUCKY enough and your chassis just burn or malfunction for any failure, you will have 75 VMs go down at 1 time and your HA and DRS is not worked at all. You will definitely screw and whack by your business or boss in this case. If we do not have enough capex to start with 2 blade chassis for HA in the virtualization, I will suggest to stick with 1U or 2U rack mount servers to minimize the risk of the business. I am impressed with the blade technology today, but just to start with 1 single chassis for HA and redundancy purpose, will not be my call.

Tags: Blade, Cisco, CPU, DRS, ESX, HA, Memory, VM, Xsigo

How To Enable Root Password for Single User Mode on vSphere 4

Jas — Thu, 11 Jun 2009 03:01:05 +0000

You can easily found “how to reset the root password on ESX” articles on the web for an example VMware KB article 1317898, xtravirt, or Petri.

However, unauthorized entry into single user mode is a risk. For security enhancement, you should enable password protect GRUB and enable root password for single user mode on vSphere 4.

How To Enable Root Password for Single User Mode on vSphere 4

Login to vSphere server as root
Edit /etc/inittab file
# vi /etc/inittab
Insert “~~:S:wait:/sbin/sulogin” and reboot

What is this mean? man inittab shows id:runlevels:action:process id = is a unique sequence of 1-4 characters which identifies an entry in inittab runlevels = lists the runlevels for which the specified action should be taken action = describes which action should be taken. process = specifies the process to be executed. S = Single user mode wait = The process will be started once when the specified runlevel is entered and init will wait for its termination.

You should be able to see password prompt during single user mode boot up

Password protecting GRUB
Note: This may NOT really helpful to anyone of you because you’re require to enter password during boot up.

Login to vSphere server as root
Type: # /sbin/grub-md5-crypt
Copy the encrypted password(e.g.$1$LgZD4/$vgg6d30on18oNlUB6FVew1) and paste into /boot/grub/grub.conf as example show below
You’re prompt to enter GRUB password as you enter just now before server boot up

Tags: enable, ESX, grub, password, root, security, VMware, vSphere