How to prevent HP SIM from scanning the VMotion port

If you run your ESXi hosts on HP hardware and have a look at the vmkernel.log files from time to time then you have probably already stumbled over messages like these:

vmkernel: cpu4:2741)MigrateNet: vm 2741: 1982: Accepted connection from <x.x.x.x>
vmkernel: cpu4:2741)MigrateNet: vm 2741: 2052: dataSocket 0x41002750c600 receive buffer size is 563560
vmkernel: cpu4:2741)WARNING: Migrate: 215: Invalid message type for new connection: 542393671.  Expecting message of type INIT (0).

Instead of x.x.x.x you will see an IP address that might be familiar to you: It belongs to a server that has the HP System Insight Manager (SIM) software installed for inventorying / managing / monitoring hardware devices in your network. This software is commonly used in HP shops, because it does a fairly good job with monitoring the hardware health of your servers and alerting if something is wrong, and this basic functionality is for free.

A VMware Storage vMotion riddle - Can you solve it?

It is a while ago now that I tried this, and I always wanted to blog about the result, but was never really sure how to present it. I think I found a fun way now ...

For those of you who are not aware of what Storage vMotion is: It is a functionality that is available in the more advanced editions of vSphere, and it allows you to migrate a VM from one datastore to another while it is running. This has been around for a while now, but is still a very cool feature. Soon after it became generally available I was thinking about this little experiment:

How to build device drivers for ESXi 5.x

Since I published my ESXi-Customizer and ESXi-Customizer-PS tools to slipstream driver packages into an ESXi installation ISO I was asked dozens of times if I can provide a driver for the unsupported device xyz or whether I can give instructions on building such a driver. So far my answer was always No, because - although I'm quite familiar with using Linux - I do not have any of the Linux kernel hacking skills that I thought would be required to do this.

ESXi embedded vs. ESXi installable FAQ

With the rise of ESXi - starting with version 3.5 in 2007/8 and now being the exclusive type-1 hypervisor architecture of VMware - there has always been some confusion about the meaning of the terms "ESXi embedded" vs. "ESXi installable".

With this blog post I will try to answer the FAQs around this topic and provide some useful background information.

The not-so-zero downtime VMware Tools Upgrade in vSphere 5.1

One of the cool new features of vSphere 5.1 is something that was announced as "Zero downtime VMware Tools upgrade". On my personal Top 5 list of vSphere 5.1 new features I even rated it #2, not without being skeptical about the zero downtime promise ...

A recent post by William Lam on the VMware vSphere Blog clarifies in what scenarios the zero downtime really applies. It is worth being fully read, but for readers who are always in a rush (or have a too short attention span ;-) I will wrap it up in a few bullet points:

• It works for Windows guests only, starting with Windows Vista
• If device drivers that are needed for booting (Display, vmscsi, pvscsi) are updated then a reboot is still required
• KB2015163 explains in detail if and when a reboot is still required after updating the Tools in a Windows VM

Please note: Given the fact that device drivers are rarely updated this is still a great progress compared to the pre-5.1 VMware Tools that would always require a reboot after an update!