List VMFS extents in ESXi

Run the esxcli storage vmfs extent list command to generate a list of extents for each volume and mapping from device name to UUID.

You see output similar to:

Volume Name VMFS UUID Extent Number Device Name Partition
------------ ----------------------------------- ------------- ------------------------------------ ---------
esxi-local 4e0d86e1-0db6f826-6991-d8d3855ff8d6 0 mpx.vmhba2:C0:T0:L0 3
datastore1 4d4ac840-c1386fa0-9f6d-0050569300a7 0naa.6006016094602800364ce22e3825e011 1
vmfs5 4dad8f16-911648ca-d660-d8d38563e658 0naa.600601609460280052eb8621b73ae011 1

This host has no isolation addresses defined as required by vSphere HA

Had some troubles with an ESXi 5.5 host the past week and rebuilt some of the networking which included removing a vmkernel and re-adding to a standard vSwitch and then setting up VMotion and Management tags on it.

Came across the following error on my host in vSphere Client:


To resolve this issue, I needed to make sure that there is a default gateway on the port group that the VMotion vmkernel is on.

Click on the ESXi Host then navigate to Configuration > Networking and on the VMkernel Port that I’m using for VMotion, click Properties…


Next, I examine properties of the VMotion VMkernel.


Looking at the IP Settings tab, I see there is no VMkernel Default Gateway defined, so I clicked Edit…


I entered in my default gateway and clicked OK and then OK again to exit the switch properties dialog.


Finally, I right-click on the ESXi host and click Reconfigure for vSphere HA


At this point, no additional errors are reported for my ESXi host.  =)

Monitor ESXi Free using SNMP

ESXi 4.1 and 5.0 Enable SNMP

SSH to host and edit the SNMP.XML file:

vi /etc/vmware/snmp.xml

Make the following changes:


Restart management agents with the following command:

/etc/init.d/hostd restart

On ESXi 5.1 and 5.5 enable SNMP

SSH to host and run the following command:

esxcli system snmp set --communities=public --enable=yes --targets=

Test SNMP trap

vicfg-snmp --server <ESXiServerIP> --username root --password <Password> --test

Reviewing the SNMP configuration

When I look at my SNMP configuration using vCLI (once again, this is a read operation so I can use vCLI), I see the following.

vi-admin@vma:~> vicfg-snmp --server <ESXiServerIP> --username root --password <Password> -s

Current SNMP agent settings:
Enabled : 1
UDP port : 161

Communities :

Notification targets :

Options :

vCenter Converter unable to see disks on source

I’m working on converting a physical 2008 R2 server to a virtual machine for ESX 4.1.  I installed vCenter Converter Standalone 4.3 on this machine and ran through the wizard.  When I got to the disk configuration, nothing was listed.


Some research pointed me to this VMware KB article indicating to check the logs which are located in C:ProgramDataVMwareVMware vCenter Converter Standalonelogs.


Upon reviewing the logs, I see the following error:

[#1] [2015-01-27 11:31:16.775 04316 warning 'App'] Failed to get info for \.PhysicalDrive0: error Read \.PhysicalDrive0 disk layout: Incorrect function (1)

Researching this error, I arrive at another VMware KB article which indicates GPT partition support was not available in vCenter Converter editions lower than 5.1 (I had installed 4.3).



Proxmox VE 3.2 Installation Screenshots

Installation of Proxmox VE 3.2 on an ESX 4.1 host. Note that KVM in Proxmox VE is not supported due to VT-x virtualization not being supported in ESX 4.1. ESXi 5.0+ support VT-x virtualization which would allow for Proxmox VE KVM support. OpenVZ containers in Proxmox still work without issue.

Hyper-V: Error applying Virtual Switch Properties changes

I got the following error when attempting to create a Virtual Switch in Hyper-V on Windows 8.1.


Error applying Virtual Switch Properties changes

I resolved this by removing Oracle VirtualBox.  Some how this was causing the issue.  I’ll research it at a later date to get a specific reason for the failure.

Hyper-V: Synthetic SCSI Controller Error When Booting from ISO

Forgive my ignorance, but this just pissed me off. I downloaded Server 2012 R2 from TechNet. I created myself a nice Hyper-V guest VM on my Windows 8.1 x64 system. I then spent a good 30 minutes researching what the $@#! this error message meant when trying to power my VM on after attaching the downloaded ISO to it. I read everything from a permissions problem, path length problem, etc. I found the answer. Finally.


The Solution

First, I have a question. Why is this a solution? What is it that is so special about this that makes it work!? Is it a file stream or something?

Ok – the solution. Are you ready? Seriously?

Make a copy of the ISO and mount that ISO to the VM’s DVD drive.



Receiving a BSOD on a Windows Server 2012 RTM fresh install processing updates. This is a Hyper-V VM.


Windbg Analysis

0: kd> .bugcheck
Bugcheck code 00000109
Arguments a3a01f58`921465fa b3b72bde`e4946739 00000000`000001a0 00000000`00000007
0: kd> !analyze -v
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
 or data. See
2) A developer attempted to set a normal kernel breakpoint using a kernel
 debugger that was not attached when the system was booted. Normal breakpoints,
 bp, can only be set if the debugger is attached at boot time. Hardware
 breakpoints, ba, can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arg1: a3a01f58921465fa, Reserved
Arg2: b3b72bdee4946739, Reserved
Arg3: 00000000000001a0, Failure type dependent information
Arg4: 0000000000000007, Type of corrupted region, can be
	0 : A generic data region
	1 : Modification of a function or .pdata
	2 : A processor IDT
	3 : A processor GDT
	4 : Type 1 process list corruption
	5 : Type 2 process list corruption
	6 : Debug routine modification
	7 : Critical MSR modification

Debugging Details:




PROCESS_NAME:  mscorsvw.exe


ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre


fffff800`494778a8 00000000`00000000 : 00000000`00000109 a3a01f58`921465fa b3b72bde`e4946739 00000000`000001a0 : nt!KeBugCheckEx



FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image







FAILURE_ID_HASH:  {75814664-faf6-4b70-bbc7-dc592132ecdd}

Followup: MachineOwner

Update 1: Applying Security Updates

I decided to apply just Security Updates right now. So far so good.


After that completed, these are the remaining updates for this pass.


I will install these on a one-by-one basis.

Interestingly enough, that first update (685KB) failed install; re-checked for updates and there was only one update (9.6MB) so I assume it to have been a roll-up? Anyway it installed fine.

Now, I re-checked updates and I have a Windows 2012 R2 Update (~800MB).


Working on installing this now.

That update installed, ran check and found additional updates; those installed as well.

One last update remains, 97MB and it installed and rebooted seemingly OK.


After prompt to restart, got the following error on boot though:


Booted back into Windows OK but I see the update did not install.

This update is the Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update rollup: May 2014

Prerequisite indicates KB2919355.

Checking system for KB2919355 shows I have it:


Re-attempting to install this update.


All updates installed, however, still getting a Bugcheck code of 0x109 randomly.

vCenter Converter fails to import machine at 1%

I got kicked in the face by this again, and I even had the resolution documented internally.  Lost 45 minutes looking through logs before I finally search VMware KB for it.  Argv!

Unexpected exception: converter.fault.clonefault
(converter.fault.CloneFault) {
dynamicType = ,
faultCause = (vmodl.MethodFault) null,
description = Unknown exception,
msg = ,

This is caused by the source computer not being able to communicate with the ESX server by DNS resolution. Simply added the DNS entry into c:windowssystem32etchosts and I was good to go.

VMware’s KB on this: