VM /ETC

Posts Tagged ‘esx’

VMware has released Update 4 (U4) of ESX and ESXi. There are some new features available with these latest builds, so check out the Release Notes of each product (linked below).

Although there are a lot of new enhancements, probably the biggest surprise for me was the experimental support for PXE booting ESXi U4. PXE boot allows stateless servers without local hard drives. For a “how to” on PXE booting ESXi 3.5 U4 check out VMware KB Article 1008971

“The main benefit of PXE booting ESX Server 3i version 3.5 Update 4 is that it allows you to run the deployment on systems with no disk or other local persistent storage. Furthermore, PXE booting greatly simplifies both the booting and upgrading processes. Therefore, scaling to many machines is greatly facilitated. No manual installation steps are necessary when the system is fully-realized.”

This sounds like an obvious Cloud enabling technology to me!

In the past, Chris Wolf and Mike Dipetrillo both gave us glimpses of a PXE boot future for ESXi. As both bloggers have described, it appears VMware architect Lance Berc is the man to thank for this new feature. Check out their posts for more info on what is possible and how it is done.

Another major enhancement of Update 4 in my opinion is the expanded and improved Enhanced VMXnet virtual network driver. Improved network performance is now possible for the 32 bit versions of Windows Server 2003 as well as Windows XP. Update 4 appears to make my recent post on enabling the VMXnet driver obsolete!

I’ll highlight (using cut and pastes) what else caught my attention from the Release Notes of both ESX and ESXi in this rest of this post. Read the rest of this entry »

A few virtualization bloggers have reported that they received an alert email from VMware about an I/O failure issue involving iSCSI or Fiber Channel (FC) SANs. There is also an alert currently dispalyed at http://www.vmware.com/support. In summary, an indefinite block occurs between ESXi/ESX 3.5 Update 3 hosts and VMFS 3 Luns which results in all paths to the storage entering a standby state. The issue is apparently isolated to the Update 3 version only.

Eric Sloof is one blogger that received the email and he has published his copy on his NTPro.nl blog. Here’s a brief quote from the email about the issue:

PROBLEM STATEMENT AND SYMPTONS:

• ESX or ESXi Host may get disconnected from Virtual Center
• All paths to the LUNs are in standby state
• Esxcfg-rescan might take a long tome to complete or never complete (hung)
• VMKernel logs show entries similar to the following:
• Queue for device vml.02001600006006016086741d00c6a0bc934902dd115241 49442035 has been blocked for 6399 seconds.
• Please refer to KB 1008130.

SOLUTION:

A reboot is required to clear this condition.

VMware is working on a patch to address this issue. The knowledge base article for this issue will be updated after the patch is available.

VMware KB 1008130 is titled VMware ESX and ESXi 3.5 U3 I/O failure on SAN LUN(s) and LUN queue is blocked indefinitely and provides the pattern of vmkernel messages that identify you have this issue:

Error messages matching this pattern are repeated continually in vmkernel:
<date and time> <hostname> vmkernel: <server uptime> cpu6:1177)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 7 seconds.
<date and time> <hostname> vmkernel: <server uptime> cpu7:1184)SCSI: 675: Queue for device vml.<Vol. Dev. ID> has been blocked for 6399 seconds.

As stated in both the email and the KB article, unfortunately the only solution is to reboot your ESXi/ESX 3.5 Update 3 hosts until VMware is able to provide a patch.

Jason Boche posted a VMware VI network communications and port usage diagram that I had to have a copy of for my knowledge base. The diagram is apparently collaboration between Jason and Nigel Metheringham that was started on communities.vmware .com. The result is a single page solution to important port information that I always seem to have to dig out of the VMware installation and quick start manuals.

Here’s an image of the current version of the diagram. Go to the post on boche.net for the .pdf version. Read the rest of this entry »

I received notice today about a project implementing ESX on IBM Blades and using System i for shared storage. After first doing a double take to make sure I read the email right, I did some quick research and found the following from the VMTN Communities:

VMware Communities: ESX on the IBM System i

“So how does VMware fit in with the System i? Well in a nut shell – The System i (which a lot of big companies have) can act as an iSCSI SAN, and you can boot IBM BladeServers and IBM System x Servers from this SAN, and have your shared storage too! Why is that so great? Because the IBM System i is one of the most reliable pieces of hardware on the planet! Because your company probably already has one! Because you can have a great backup and recovery platform!”

In case you are wondering what IBM System i is exactly, Read the rest of this entry »

I ran into another ESX configuration issue this week that seems to continue to hang around even though it was identified quite a long time ago. After a fresh install of two different ESX 3.5 Update 2 servers (installed from the 110268 build .iso), I was configuring NTP time sync from the VI Client (installed from the VirtualCenter 2.5 Update 3 119825 build .iso) and was unable to change the NTP server. The error message window told me “failed to change host configuration”. Most frustrating to me is the fact that I have been able to change the NTP configuration from the VI client in past versions of ESX 3.5.

I was able to manually change the NTP configuration by digging out the related recommendations from the VMTN Communities thread VMware Communities: ESX 3.5 – Time Configuration = “Failed …. I have summarized my resolution steps in the rest of this post. Note that I did not have to modify all of the files and settings (steptickers, esx firewall) as previously required (and scripted) when manually changing NTP sync in ESX version 3.0.X.

Early in the VMTN thread was the advice: Read the rest of this entry »

There has been an ongoing discussion this week about a possible limitation of VMware’s SVVP validation for Microsoft application support. I first heard about it from Scott Lowe’s post VMware ESX SVVP Apparently Limited. Scott wrote:

“According to this article, the validation is handled per CPU architecture, per memory configuration. So, apparently VMware ESX is validated on an AMD system with 4GB of RAM, but that’s about it.”

Scott asked his readers for additional information to back up the LeMagIT.fr article’s claim and if there was any knowledge of additional validation in the works by VMware. Apparently in response to the concerns of partners and customers, VMware sent an internal communication on this subject, and as of yesterday a couple of blogs have posted an explanation with details about the status of the SVVP validation. Chad Sakac, EMC (and VMware mothership) Senior Director, posted “SVVP – how does it work?” and Kenon Owens, VMware employee, posted “What’s the deal with SVVP“.

Bottom line is that VMware’s SVVP validation is solid and not a concern. Chad is so confident that he has made an open offer to any concerned VMware customers: Read the rest of this entry »

Some VM /ETC readers may remember a weekly series of posts I was doing earlier this year – “things that make you go hmmm“. Well, the August 12 ESX/ESXi 3.5 Update 2 BUG definitely deserves a resurrection of that series and a post all to itself. Although this topic is still a little too sensitive to be humorous today, I’ve included a mix of comic and serious links. Hopefully we can all look back and at least chuckle about these events sometime in the future. So, here is a sampling of of the various reactions and opinions on the VMware time bomb bug from around the internet. Laugh if you can. After all, it’s Friday … Read the rest of this entry »