Yellow Bricks

by Duncan Epping

vmkping results in “syscall version mismatch (compiled: 0x7616c4e3, kernel: 0x50f63116)”

· ·

When troubleshooting a VMotion problem on an unpatched ESX 3.0.2 update 1 host today I wanted to use vmkping. This constantly resulted in the following error message:

syscall version mismatch (compiled: 0x7616c4e3, kernel: 0x50f63116)

I did not find any useful info on google so I checked the VMware knowledge base, maybe some over at VMware can read my mind or it’s a pure coincidence they just updated the following KB article, it seems to be a bug which is fixed in ESX-1002424. It’s actually mentioned in the release notes… I should read those more often I guess.

New version of ESX 3.5 and patches for 3.0.x

· ·

VMware just released a new version of the ESX 3.5 ISO according to their download site. The release notes haven’t been update yet so unfortunately I can’t tell you what’s included, but my guess would be the patches released on the 17th of January.

Latest Released Version: 3.5.0 | 02/20/08 | 64607 | 565 MB

There are no new patches available for 3.5 at the moment, but they did patch 3.0.x and the following is fixed in these patches(8 patches for 3.0.2, over 140MB):

  • Security Update to the Samba Package
  • Security Updates to the Python Package
  • Fix for aacraid SCSI Driver Security Issue
  • Virtual Machines on the ESX Server host do not power ON automatically
  • ESX Server host might stop responding when a CD-ROM drive is accessed
  • iSCSI LUNs in the pass-through mode might cause the ESX Server host to stop responding
  • Fixes for Remote-Console Black-out, OpenSolaris Boot Delay, Duplicate Packet Issue; Support for Virtual Machines to Share Generic SCSI Devices
  • Fixes for VMware Tools Installer

By the way I signed in on the patch/updates email and haven’t received anything yet… Did any of you guys receive anything?

HA advanced options

· ·

PeterB posted a topic about all known HA advanced options on the Dutch VMUG. If anyone has more options please post ’em and let’s try to make this list as long as possible:

  • das.failuredetectiontime – Amount of milliseconds, timeout time for isolation response action
  • das.isolationaddress[0-9] – IP address the ESX hosts uses validating if it is isolated from the network or not. It will use the default gateway by default. With this setting additional addresses can be configured for use.
  • das.poweroffonisolation – Values are False or True, this is for setting the isolation response. Default a VM will be powered off.
  • das.vmMemoryMinMB – Higher values will reserve more space for failovers.
  • das.vmCpuMinMHz – Higher values will reserve more space for failovers.
  • das.defaultfailoverhost – Value is a hostname, this host will be the primary failover host.

VMworld time table

· ·

For those attending the VMworld, check out the time table Rene created in Excel. Will come in handy when deciding which session to attend!

I am attending VMworld Europe 2008 Next week in Cannes. Today I was looking what kind of sessions wil be presented. On the VMworld site there is a link to see a long list of available sessions, but I found this list hard to use. I made a nice timetable in Excel to see which session is on what time in which room.

VMworld-EUROPE-2008-Timetable

ESX 3.5 and weird DRS/HA behaviour…

· ·

During the last couple of ESX 3.5 and VC 2.5 implementations I encountered some weird DRS/HA behavior:

  1. During the reboot of a VM ESX decided to vmotion the VM, as you can imagine this took a lot longer than normal due to the memory being excessively active.
  2. When the DRS Affinity Rules in a two cluster node is set to “seperate” two specific virtual machines VMware has a hard time relocating a VM when a host goes into “maintenance mode”. I can imagine why this happens but it’s definitely not something that’s suppose to happen in my opinion. It’s a Admin initiated manual action it should overrule all affinity settings.

So let me hear which weird behavior you noticed with ESX 3.5 / VC 2.5….