I've read this excellent article by Cormac Hogan explaining why and when a Virtual Machine receives a "stun". This post is a follow-up explaining how you can determine the duration of a Virtual Machine stun on the most common vSphere functions:
Read More »How long are Virtual Machines stunned for Snapshots and vMotion?
Intel NUCs with ESXi are being used as home servers and in many home labs. If you are generally interested in running ESXi on Intel NUCs, read this post first. Officially, it is limited to 16GB memory which might come a little bit short for virtualization labs. Recently Crucial has launched 16GB DDR3L modules for an affordable price (Intelligent Memory was the first in the market with 16GB modules, but they were quite expensive). I've ordered two Crucial 16GB modules (CT204864BF160B) and tested them in my 5th Gen Intel NUC (NUC5i5MYHE).
When you open a Support Request (SR) at VMware, the Global Support Services usually requests you to collect diagnostic information. You can create this log bundle with a special command line tool (vm-support), with the vSphere (Web-)Client or with the API. No matter how you create the bundle the result is always the same: a .tgz file containing your ESXi Host name and the creation date with a size of about 30 - 300MB.
This post explains what's inside this log bundle, but instead of simply extracting the file and looking at the result, I am going to take a look on how the file is created and what's part of the process.
Why is it important to know? Because it does not only contain data that allows VMware GSS to identify your issue, but also to help yourself to enhance your troubleshooting skills. The script gathers the output of many useful commands and there is nearly no black magic involved. You do not need special tools or internal VMware knowledge to make use of this log bundle.
In my latest post USB Devices as VMFS Datastore in vSphere ESXi 6.0 I had a problem with USB 3.0 devices that are detected as USB 2 in ESXi. I know that USB 3.0, also known as eXtensible Host Controller Interface (xHCI), is supported in ESXi 6.0 and ESXi 5.5 Build 2143827 or later. Unfortunately all of my devices are detected as USB 2.1, despite the USB 3 hub was visible. This problem applies to both, USB devices in path-through mode, and USB devices mounted from the command line with usbarbitrator disabled. The solution was quite simple and not related to an ESXi, but to a UEFI configuration.
Read More »USB 3.0 devices detected as USB 2 in ESXi 6.0 and 5.5
Many ESXi installations are running on SD Cards or flash drives. In my opinion, it's a good practice. The hypervisor itself requires about 150MB, and the full installation on a SD Card is less than 1GB, without diagnostic partitions. VMware recommends using a 4GB or larger USB/SD device. When you want to install ESXi and you don't use auto-deploy, install servers or other automation tools you typically have to mount an ESXi ISO file to your server management system (iLO, iDRAC,...) or work with a physical installation media. This is somewhat slow and uncomfortable, but there is a little trick to make the installation faster.
You can prepare the USB/SD device with the ESXi installer, plug it into your server and install it to the device itself by overwriting the installer. You can also use customized installers when your hardware requires special drivers.Read More »Pre-installed ESXi 6.0 on SD Cards or Flash Drives
In the last years I've seen many requests in forums and blogs where people are trying to use USB devices like USB sticks or external hard disks as VMFS formatted datastore. It was actually possible in vSphere 5, but very picky. Some USB flash drives were working, others not. In vSphere 6, this behavior has been changed obviously. This post explains how you can use USB devices as datastore on your ESXi host. Of course, this is neither a supported, nor a performant storage solution, so use at your own risk.Read More »USB Devices as VMFS Datastore in vSphere ESXi 6.0
This post explains how you can troubleshoot network problems by capturing network traces of ESXi host by using the tcpdump-uw and pktcap-uw utility. The pktcap-uw tool is an enhanced packet capture and analysis tool that can be used in place of the legacy tcpdump-uw tool. The pktcap-uw tool is included by default in ESXi 5.5 and later. This post explains the main differences of both tools and how to use them.
Capabilities of tcpdump-uw and pktcap-uw
The tcpdump-uw utility captures traffic from VMkernel adapters. The pktcap-uw utility, introduced in ESXi 5.5 can capture traffic that flows through physical network adapters, VMkernel adapters, and virtual machines adapters.
But it's more complex...
Read More »ESXi Network Troubleshooting with tcpdump-uw and pktcap-uw
This post explains how you can hide a VMware based Virtual Machine from designated users or the entire vCenter Server infrastructure. I'am explaining different scenarios where you can hide Virtual Machines including:
To clarify, this post does not cover techniques to cloak that the Guest OS is running on a virtual machine, instead of bare metal.
The Linux Version of the vCenter Server is not new anymore but with vSphere 6.0 the vCenter Server Appliance (VCSA) has overtaken the Windows Version in many aspects. The completely rewritten linked mode removes the need for a Windows-based vCenter and the scalability of both appliances are identical.
VCSA6 is delivered as appliance based on openSUSE. Nevertheless its a Linux, VMware want's you to use the GUI. Unless you are in a testing environment I would highly recommend to limit shell usage to the following usage scenarios:
You might be aware of the 3 critical security issues that VMware has published and fixed a couple of days ago in VMSA-2015-0007. The information provided in the security advisory regarding the first issue, CVE-2015-5177 (ESXi OpenSLP Remote Code Execution), are:
VMware ESXi contains a double free flaw in OpenSLP's SLPDProcessMessage() function. Exploitation of this issue may allow an unauthenticated attacker to remotely execute code on the ESXi host.
Relevant Releases
VMware ESXi 5.5 without patch ESXi550-201509101
VMware ESXi 5.1 without patch ESXi510-201510101
VMware ESXi 5.0 without patch ESXi500-201510101
In this post I am trying to give a better understanding of the vulnerability and its consequences. Please note that the information in this post are my personal opinions. I cannot guarantee that these information are accurate. The main fact is that VMware has published a fix and you should install the patch to be on the safe side. In the real world, you might have something like a "change process" where you can't rollout the patch for hundreds of systems immediately. Or you have a single ESXi that you don't want to reboot at the moment. In this situation, this post tries to help...
Read More »More Information on CVE-2015-5177 (ESXi OpenSLP Remote Code Execution)