Virtualization, Cloud, Infrastructure and all that stuff in-between
My ramblings on the stuff that holds it all together
VMware AppSpeed Probes and more 2% Maintenance Mode Problems
Following on from my last post on problems entering maintenance mode with FT-enabled VMs, I seem to have found another one – if you have the rather excellent AppSpeed product deployed on an ESX cluster and you want to put a host into maintenance mode it gets stuck at 2% as it can’t move the AppSpeed probe VM onto an alternative host
If you try to manually vMotion the problematic probe off to another host in the cluster you get the following error
If you shutdown or suspend the AppSpeed probe VM then the switch to maintenance mode continues as expected.
This would make sense as it plugs directly into a dedicated vSwitch on that host to monitor network traffic so vMotioning it off wouldn’t be of any use – assuming the other nodes in the cluster are also running AppSpeed probes.
However it would be great if there was a more automated way to handle this? guess it’s tricky as on one hand its great that AppSpeed doesn’t rely on any ESX-host agents and is essentially self-contained with probes running as VM appliances but on the other hand the probe doesn’t know the guest is being put into maintenance mode so should be shut down/suspended rather than vMotioned to an alternative host.
There is integration with the vCenter server via a plug-in so maybe in future versions that could trap a maintenance mode event and initiate (or suggest) shutting down the AppSpeed probes.
Note that AppSpeed will support Maintenance mode in version 1.0.1 (planned to be released in mid December). Probes will be automatically powered off, when entering “Maintenance mode” on hosts with a Probes installed.
Great – thanks for posting
This is not the only probe type appliance that needs to trap a maintenance mode event….