srwsol's Posts

I'm having the same problem.  Originally I thought the problem was related to the new version of vCenter server in conjunction with ESXi 6.0u2, as I upgraded vCenter server first.  However, then ... See more...
I'm having the same problem.  Originally I thought the problem was related to the new version of vCenter server in conjunction with ESXi 6.0u2, as I upgraded vCenter server first.  However, then I upgraded one of my hosts to 6.5 from 6.0u2 and after doing that I found that the sensors were still missing from the new version of vCenter server, and they are also missing from the html5 client on the upgraded host.   However, the sensors are still present if you connect directly to the upgraded host from the old C client (you can't connect the old C client to the new version of vCenter Server).
I upgraded one host to ESXi 6.5 and now the hardware sensors do not appear on the host html5 client nor the vCenter Server html5 client or the Flash client.   However the hardware sensors do appe... See more...
I upgraded one host to ESXi 6.5 and now the hardware sensors do not appear on the host html5 client nor the vCenter Server html5 client or the Flash client.   However the hardware sensors do appear in the old C client when it is connected directly to the host.
Afraid that's not the issue.  The Hardware Status link is there, but it simply says "No Records to Display" instead of showing me the sensors. 
Hi folks: I just upgraded to vCenter Server 6.5 appliance from version 6.0, and while the upgrade went smoothly, I'm no longer able to see any hardware sensors on either of my two hosts (I hav... See more...
Hi folks: I just upgraded to vCenter Server 6.5 appliance from version 6.0, and while the upgrade went smoothly, I'm no longer able to see any hardware sensors on either of my two hosts (I have just the Essentials bundle).   The two hosts are still running ESXi 6.0u2.  The sensors are still there because I can see them on the old vsphere thick client when I connect directly to the hosts.  I've tried updating the sensors, resetting the sensors, shutting down and restarting the appliance, and I also tried removing one of the hosts from the appliance inventory and disassociating it, then connecting it back up again as a new host, and I still don't get any hardware sensors.  This is true on both the HTML 5 and Flash versions of the appliance client, so I don't think it's strictly a UI issue. Suggestions welcome.
I'm afraid that doesn't do the trick.  I installed Mint on a current copy of ESXi 6 with the latest hardware version (version 11), installed the current VMWare tools,  and had the problem.  I use... See more...
I'm afraid that doesn't do the trick.  I installed Mint on a current copy of ESXi 6 with the latest hardware version (version 11), installed the current VMWare tools,  and had the problem.  I used VMWare Converter to convert the VM to the latest Workstation product and still had the problem with Hardware version 11.  As soon as I upgraded to hardware version 12 on Workstation the problem went away.   Others have noted the same issue.  Hardware version 12 the only fix for this as far as I know.
Does anyone know when hardware version 12 will be available for VMs running under ESXi 6?    There is an issue with the Linux Cinnamon desktop under version 11 where the foreground windows are tr... See more...
Does anyone know when hardware version 12 will be available for VMs running under ESXi 6?    There is an issue with the Linux Cinnamon desktop under version 11 where the foreground windows are translucent and allow what's underneath to bleed through into them, making them difficult to read.  This is a bug in OpenGL 2 in combination with the VMWare video drivers, but it works fine with OpenGL 3 which is supported under hardware version 12 that is already out in the latest VMWare workstation product.
The passthrough functionality operates at the PCI device level, which would require that the USB controller on the motherboard be passed through to the VM.  Unfortunately if you passthrough the U... See more...
The passthrough functionality operates at the PCI device level, which would require that the USB controller on the motherboard be passed through to the VM.  Unfortunately if you passthrough the USB controller on the motherboard to the VM you will likely lose all console access to ESXi.  I've found through experimentation that even if there are multiple USB controllers on the motherboard they don't often work well when setup for PCI pass through.  If you must have that particular USB hub under direct control of a VM for some reason the best way I can think of to do it is to purchase an additional USB PCI card and install it in a PCI slot.  You can then pass through just that PCI device to the VM and connect the hub to the USB port of that card.  In that setup the VM will have full access to and control over the hub.
That did the trick!   BTW that was some very good detective work on your part figuring out which quirk setting would achieve what the poster in the other thread achieved by disabling usb-storage.... See more...
That did the trick!   BTW that was some very good detective work on your part figuring out which quirk setting would achieve what the poster in the other thread achieved by disabling usb-storage.  Thank you very much! 
Hi folks: I'm having a problem with a particular USB 3 device in trying to connect it to a VM.  The device is a Toshiba USB 3 5tb hard drive, and it's recognized by ESXi as I can see it when I... See more...
Hi folks: I'm having a problem with a particular USB 3 device in trying to connect it to a VM.  The device is a Toshiba USB 3 5tb hard drive, and it's recognized by ESXi as I can see it when I do a lsusb command, but it's never offered as an available choice to connect to any VM.  I've tried restarting all the management agents, rebooting ESXi with the device plugged in so that it's detected immediately at bootup.  I've tried using both the vcenter server appliance web client and the native C client.  It simply never appears as a choice just as if it's not there.  Other USB 3 devices, including a Startech gigabit network device and another 2tb Toshiba USB drive appear as choices, so it doesn't appear to be an issue with USB 3 devices as a whole.  I've connected to other computers and even to an Arch Linux VM under the same ESXi that has a Startech USB 3 controller connected to it via PCI Passthrough and it works in all those places.  I even tried connecting it to a USB 2 port just for the heck of it, and I got the same result (invisible to VMs)  Here is what information I have via the logs.  I see some entries about the device being suspended in the vmkernel log, but I don't know if that's normal procedure for a device until it's assigned to a VM.  Any ideas of what's wrong or how to fix it welcome. lsusb [root@naplesesxi:/var/log] lsusb Bus 004 Device 011: ID 0480:d011 Toshiba America Info. Systems, Inc. Bus 004 Device 008: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Bus 003 Device 003: ID 2109:2811 Bus 004 Device 007: ID 2109:8110 Bus 002 Device 012: ID 1058:1003 Western Digital Technologies, Inc. Elements 1000 GB Bus 002 Device 007: ID 059b:0277 Iomega Corp. Bus 002 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS Bus 002 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 004 Device 002: ID 0781:5583 SanDisk Corp. Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [root@naplesesxi:/var/log] lsusb detail [root@naplesesxi:/var/log] lsusb -v -d 0480:d011 Bus 004 Device 011: ID 0480:d011 Toshiba America Info. Systems, Inc. Device Descriptor:   bLength                18   bDescriptorType         1   bcdUSB               3.00   bDeviceClass            0 (Defined at Interface level)   bDeviceSubClass         0   bDeviceProtocol         0   bMaxPacketSize0         9   idVendor           0x0480 Toshiba America Info. Systems, Inc.   idProduct          0xd011   bcdDevice            6.07   iManufacturer           1 TOSHIBA   iProduct                2 External USB 3.0   iSerial                 3 20140426016164   bNumConfigurations      1   Configuration Descriptor:     bLength                 9     bDescriptorType         2     wTotalLength           44     bNumInterfaces          1     bConfigurationValue     1     iConfiguration          0     bmAttributes         0xc0       Self Powered     MaxPower                2mA     Interface Descriptor:       bLength                 9       bDescriptorType         4       bInterfaceNumber        0       bAlternateSetting       0       bNumEndpoints           2       bInterfaceClass         8 Mass Storage       bInterfaceSubClass      6 SCSI       bInterfaceProtocol     80 Bulk-Only       iInterface              0       Endpoint Descriptor:         bLength                 7         bDescriptorType         5         bEndpointAddress     0x81  EP 1 IN         bmAttributes            2           Transfer Type            Bulk           Synch Type               None           Usage Type               Data         wMaxPacketSize     0x0400  1x 1024 bytes         bInterval               0         bMaxBurst              14       Endpoint Descriptor:         bLength                 7         bDescriptorType         5         bEndpointAddress     0x02  EP 2 OUT         bmAttributes            2           Transfer Type            Bulk           Synch Type               None           Usage Type               Data         wMaxPacketSize     0x0400  1x 1024 bytes         bInterval               0         bMaxBurst              14 Binary Object Store Descriptor:   bLength                 5   bDescriptorType        15   wTotalLength           42   bNumDeviceCaps          3   USB 2.0 Extension Device Capability:     bLength                 7     bDescriptorType        16     bDevCapabilityType      2     bmAttributes   0x00000002       Link Power Management (LPM) Supported   SuperSpeed USB Device Capability:     bLength                10     bDescriptorType        16     bDevCapabilityType      3     bmAttributes         0x00     wSpeedsSupported   0x000e       Device can operate at Full Speed (12Mbps)       Device can operate at High Speed (480Mbps)       Device can operate at SuperSpeed (5Gbps)     bFunctionalitySupport   1       Lowest fully-functional device speed is Full Speed (12Mbps)     bU1DevExitLat          10 micro seconds     bU2DevExitLat        2047 micro seconds   Container ID Device Capability:     bLength                20     bDescriptorType        16     bDevCapabilityType      4     bReserved               0     ContainerID             {14c4c0cc-6785-495d-8dcb-c74305d84121} Device Status:     0x0001   Self Powered [root@naplesesxi:/var/log] vmkernel when pluggin in drive 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb 4-4: New USB device found, idVendor=0480, idProduct=d011 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb 4-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb 4-4: Product: External USB 3.0 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb 4-4: Manufacturer: TOSHIBA 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb 4-4: SerialNumber: 20140426016164 2016-03-02T20:04:23.337Z cpu5:33148)<6>xhci_hcd 0000:00:14.0: add ep 0x81, slot id 12, new drop flags = 0x0, new add flags = 0x8 2016-03-02T20:04:23.337Z cpu5:33148)<6>xhci_hcd 0000:00:14.0: add ep 0x2, slot id 12, new drop flags = 0x0, new add flags = 0x18 2016-03-02T20:04:23.337Z cpu5:33148)<6>xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev 0x4302ab3e2bc0 2016-03-02T20:04:23.337Z cpu5:33148)<6>xhci_hcd 0000:00:14.0: New Input Control Context: 2016-03-02T20:04:23.337Z cpu5:33148)<6>xhci_hcd 0000:00:14.0: Output context after successful config ep cmd: 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb 4-4: Vendor: 0x0480, Product: 0xd011, Revision: 0x0607 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb 4-4: Interface Subclass: 0x06, Protocol: 0x50 2016-03-02T20:04:23.337Z cpu5:33148)WARNING: LinScsiLLD: scsi_add_host:573: vmkAdapter (usb-storage) sgMaxEntries rounded to 255. Reported size was 65535 2016-03-02T20:04:23.337Z cpu5:33148)LinPCI: LinuxPCI_DeviceIsPAECapable:581: PAE capable device at 0000:00:14.0 2016-03-02T20:04:23.337Z cpu5:33148)DMA: 646: DMA Engine 'vmhba50' created using mapper 'DMANull'. 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb-storage 4-4:1.0: interface is claimed by usb-storage 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb 4-4: device is not available for passthrough 2016-03-02T20:04:23.337Z cpu5:33148)<6>usb 4-4: usbfs: registered usb040b 2016-03-02T20:04:23.337Z cpu5:33148)<6>hub 4-0:1.0: suspended 2016-03-02T20:04:23.349Z cpu0:32819)ScsiNpiv: 1505: GetInfo for adapter vmhba50, [0x4301a7966240], max_vports=0, vports_inuse=0, linktype=0, state=0, failreason=0, sts=bad0020 2016-03-02T20:04:23.493Z cpu5:33105)<6>xhci_hcd 0000:00:14.0: xhci_hub_status_data: stopping port polling. 2016-03-02T20:04:25.340Z cpu5:33111)<6>usb usb3: suspended 2016-03-02T20:04:25.340Z cpu5:33111)<6>usb usb3: suspended 2016-03-02T20:04:34.056Z cpu6:33107)<6>usb-storage 4-4:1.0: suspended 2016-03-02T20:05:15.869Z cpu4:162661)<6>usb passthrough disabled 2016-03-02T20:05:16.059Z cpu2:162686)VC: 3551: Device rescan time 9 msec (total number of devices 5) 2016-03-02T20:05:16.059Z cpu2:162686)VC: 3554: Filesystem probe time 13 msec (devices probed 3 of 5) 2016-03-02T20:05:16.059Z cpu2:162686)VC: 3556: Refresh open volume time 1 msec 2016-03-02T20:05:16.150Z cpu1:162688)<6>usb passthrough enabled; all eligible devices will be unclaimed by kernel drivers 2016-03-02T20:05:16.235Z cpu6:162690)VC: 3551: Device rescan time 8 msec (total number of devices 5) 2016-03-02T20:05:16.235Z cpu6:162690)VC: 3554: Filesystem probe time 11 msec (devices probed 3 of 5) 2016-03-02T20:05:16.235Z cpu6:162690)VC: 3556: Refresh open volume time 1 msec 2016-03-02T20:05:16.292Z cpu2:162691)ScsiScan: 836: Path vmhba0:C0:T0:L0 supports REPORT LUNS 0x11 2016-03-02T20:05:27.898Z cpu3:162776)CMMDS: CMMDSVSIUpdateNetworkCbk:2150: RECONFIGURE of interface vmk3 with cmmds (Success). 2016-03-02T20:05:27.921Z cpu3:162776)VC: 3551: Device rescan time 9 msec (total number of devices 5) 2016-03-02T20:05:27.921Z cpu3:162776)VC: 3554: Filesystem probe time 13 msec (devices probed 3 of 5) 2016-03-02T20:05:27.921Z cpu3:162776)VC: 3556: Refresh open volume time 1 msec 2016-03-02T20:05:28.512Z cpu4:162776)Config: 680: "SIOControlFlag2" = 0, Old Value: 0, (Status: 0x0) 2016-03-02T20:05:32.679Z cpu0:162776)Config: 680: "VMOverheadGrowthLimit" = 4294967295, Old Value: 4294967295, (Status: 0x0) 2016-03-02T20:05:34.612Z cpu6:162983)TPM FixedMem: start = 0xfed40000, end = 0xfed44fff, write protect = 0 2016-03-02T20:05:46.397Z cpu7:162998 opID=73a64522)World: 15514: VC opID HB-SpecSync-host-9@0-3fda4c20-7-209f maps to vmkernel opID 73a64522 2016-03-02T20:05:46.397Z cpu7:162998 opID=73a64522)Config: 680: "HostLocalSwapDirEnabled" = 0, Old Value: 0, (Status: 0x0) 2016-03-02T20:06:00.897Z cpu3:162786 opID=478d4c8)World: 15514: VC opID HB-SpecSync-host-9@0-799bbb99-81-212f maps to vmkernel opID 478d4c8 2016-03-02T20:06:00.897Z cpu3:162786 opID=478d4c8)Config: 680: "HostLocalSwapDirEnabled" = 0, Old Value: 0, (Status: 0x0)
I was trying to copy a VM from one location to another using the file manager in the web client and I found that I'm unable to copy the data portion (i.e. the -flat part) of a virtual disk file. ... See more...
I was trying to copy a VM from one location to another using the file manager in the web client and I found that I'm unable to copy the data portion (i.e. the -flat part) of a virtual disk file.  The client silently only copies the configuration portion of the vmdk file, but not the data portion.  If you go back and try to do it again you get a duplicate file error.  Of course this must have to do with the fact that the gui hides the fact that a vmdk file is really two physical files, the portion with the configuration in it and the portion with the actual data.   Am I missing something here, or is there a trick to it that I don't know about, such as being able to force the web client to show you both physical files that make up the vmdk? I have to say that this web client is a joke.  I can't believe that they were actually going to discontinue the original client when the web client can't do simple things like download all the files in a directory, or even copy a vmdk file correctly. 
Hi folks: There was a post in the ESXi 5 discussion group about Windows 10 VMs unexpectedly crashing after about 24 hours.  I've found that this is also a problem with ESXi 6 as my Windows 10 ... See more...
Hi folks: There was a post in the ESXi 5 discussion group about Windows 10 VMs unexpectedly crashing after about 24 hours.  I've found that this is also a problem with ESXi 6 as my Windows 10 VM appeared to simply shutdown within 24 hours or so of me starting them, which I had at first attributed to some sort of activation issue.   If you are having this issue see this thread for information on the cause and a workaround until a patch to correct the problem is released: https://communities.vmware.com/message/2533457#2533457
This also fixed my Windows 10 problems.  I was getting the error within 24 hours of running any Windows 10 VM under ESXi 6, even if I hadn't reverted from a snapshot.  The VM simply wasn't runnin... See more...
This also fixed my Windows 10 problems.  I was getting the error within 24 hours of running any Windows 10 VM under ESXi 6, even if I hadn't reverted from a snapshot.  The VM simply wasn't running when I went back after a while to do something with it.  You have to scan the event log to see that this error occurred, so if you simply see that your Windows 10 VM has shutdown for no obvious reason, this is probably the problem.  At first I thought I had some sort of activation issue.
I'd say that more cores are better, and that hyperthreaded CPUs are better than non-hyperthreaded CPUs.    Here's why: 1).  A core (regular or hyperthread) can be basically equated to a vCPU. ... See more...
I'd say that more cores are better, and that hyperthreaded CPUs are better than non-hyperthreaded CPUs.    Here's why: 1).  A core (regular or hyperthread) can be basically equated to a vCPU. 2).  If you add up the number of VCPUs being used by all the VMs you are likely to have active at once and compare that total to the total number of cores + hyperthread cores on the processor(s) you will be able to tell to what extent ESXi will have to manage this resource for you.  For example, if the total number of VCPUs being used by all the active VMs is less than or equal to the number of cores + hyperthread cores in the processor then no management will be necessary because a core will always be ready to assign to a VCPU when a VM needs it.  On the other hand if there are more VCPUs active than the total core number then ESXi must manage them in that there aren't enough for every VM to be using what it wants at the same time.  Obviously the higher the ratio of active VCPUs to available cores is the harder that task becomes and the more likely one or more VMs will have to wait their turn and the slower the response time. 3).  Hyperthread cores are good because they cost very little for the benefit they give.  Remember, a hyperthread core siphons CPU cycles off of the main core it belongs to only if both are actually executing instructions at the same time.  ESXi does it's best not to schedule a VCPU to a hyperthread core if there is a regular core available instead, meaning that it won't use them until all the regular cores are assigned.  However, here's the good part.  Suppose that a VCPU for VM "A" has been assigned to main core 0 on the processor and all the other main cores are also in use.  Also assume that VM "A" has multiple VCPUs assigned to it, which means that in order for it to run multiple cores must be available.  When VM "A" gets its timeslice and it's VCPUs are mapped to physical cores, that doesn't necessarily mean that VM "A" will actually be executing instructions on both of it's assigned cores for the entire duration of its timeslice.  It may have only one process that needs CPU, and therefore is leaving the other core idle, but even if that's the case it must be assigned as many cores as it asked for because its operating system is expecting them to be there, whether being used or not.  This means that if VM "B" was assigned hyperthread core 0 which goes with the main core being utilized by VM "A" because all the other main cores were in use and ESXi had to start mapping VCPUs to hyperthread cores, VM "B" might still get more than half of the computing power of the core to the extent that VM "A" isn't actually executing instructions on the associated main core at the same time.  So this means that at worst if instructions are being executing on both the main and hyperthread core by different VMs at the same time, they each run at about half speed, but if one of them isn't actively using the core, even though one of it's VCPUs is mapped to it during its timeslice, the other VM seamlessly receives the CPU cycles the first VM isn't actively using.  In essence this allows ESXi to over commit CPU resources by having all these extra hyperthread cores available and the architecture of the chip will seamless tune them by virture how hyperthreading works. 4).  Now, the one situation where faster but fewer cores, or faster cores but no hyperthreading capability (e.g. some AMD processors) might be better is if the VMs you are intending to run are mostly single VCPU workloads and that the workload within the VM is mostly single threaded, and assuming that you aren't going to run signifigantly more VMs of this type at the same time than the number of physical CPU cores you have available.  This could be the case with workloads where most of the processing need is for mathematical calculations (e.g. scientific or engineering applications) which need to run serially and can't be broken up to take advantage of multithreading, rather than multitasked or IO based workloads like databases, email servers, web servers, etc.  In that case completing the single threaded calculation faster courtesy of the higher clock speed might yield a better result. Hope that helps.
Success!!  I finally figured out what the problem was and got it corrected.  The problem was the fact that although the latest driver vib from LSI was installed, for some reason it would not auto... See more...
Success!!  I finally figured out what the problem was and got it corrected.  The problem was the fact that although the latest driver vib from LSI was installed, for some reason it would not automatically replace the default ESXi driver lsi_mr3.  I didn't notice that although the latest driver package vib from LSI installed properly the controller was still using the original driver.  This could be seen by doing a "esxcfg-scsidev -a" command which still showed "vmhba1  lsi_mr3           link-n/a  sas.5001e67ca647e000                    (0000:0a:00.0) LSI MegaRAID SAS Fury Controller" .  The second field after the controller (vmhba1) is the current driver being used.  The driver that needed to be used was:  "vmhba1    megaraid_sas    link-n/a  unknown.vmhba   (0000:03:00.0) Avago (LSI / Symbios Logic) MegaRAID SAS Invader Controller"  . To fix this problem I had to disable the lsi_mr3 driver so that ESXi was forced to use the other one.  The procedure to do that is as follows: 1).  Verify that you have the new driver that you want EXSi to use already installed.  I'm assuming that bad things would happen if you disabled the only driver that could operate your disk controller.  Use this command to see the installed drivers:  "esxcli software vib list"  and you should get something similar to the following: [root@intelserver:~] esxcli software vib list Name                           Version                               Vendor  Acceptance Level  Install Date -----------------------------  ------------------------------------  ------  ----------------  ------------ scsi-megaraid-sas              6.608.11.00-1OEM.600.0.0.2494585      Avago   VMwareCertified   2015-07-19 lsi-mr3                        6.606.10.00-1OEM.550.0.0.1391871      LSI     VMwareCertified   2015-06-19 mtip32xx-native                3.8.5-1vmw.600.0.0.2494585            VMWARE  VMwareCertified   2015-04-28 ata-pata-amd                   0.3.10-3vmw.600.0.0.2494585           VMware  VMwareCertified   2015-04-28 ata-pata-atiixp                0.4.6-4vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 ata-pata-cmd64x                0.2.5-3vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 ata-pata-hpt3x2n               0.3.4-3vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 ata-pata-pdc2027x              1.0-3vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 ata-pata-serverworks           0.4.3-3vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 ata-pata-sil680                0.4.8-3vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 ata-pata-via                   0.3.3-2vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 block-cciss                    3.6.14-10vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 cpu-microcode                  6.0.0-0.0.2494585                     VMware  VMwareCertified   2015-04-28 ehci-ehci-hcd                  1.0-3vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 elxnet                         10.2.309.6v-1vmw.600.0.0.2494585      VMware  VMwareCertified   2015-04-28 emulex-esx-elxnetcli           10.2.309.6v-0.0.2494585               VMware  VMwareCertified   2015-04-28 esx-base                       6.0.0-0.11.2809209                    VMware  VMwareCertified   2015-07-21 esx-dvfilter-generic-fastpath  6.0.0-0.0.2494585                     VMware  VMwareCertified   2015-04-28 esx-tboot                      6.0.0-0.0.2494585                     VMware  VMwareCertified   2015-04-28 esx-xserver                    6.0.0-0.0.2494585                     VMware  VMwareCertified   2015-04-28 ima-qla4xxx                    2.02.18-1vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 ipmi-ipmi-devintf              39.1-4vmw.600.0.0.2494585             VMware  VMwareCertified   2015-04-28 ipmi-ipmi-msghandler           39.1-4vmw.600.0.0.2494585             VMware  VMwareCertified   2015-04-28 ipmi-ipmi-si-drv               39.1-4vmw.600.0.0.2494585             VMware  VMwareCertified   2015-04-28 lpfc                           10.2.309.8-2vmw.600.0.0.2494585       VMware  VMwareCertified   2015-04-28 lsi-msgpt3                     06.255.12.00-7vmw.600.0.0.2494585     VMware  VMwareCertified   2015-04-28 lsu-hp-hpsa-plugin             1.0.0-1vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 lsu-lsi-lsi-mr3-plugin         1.0.0-2vmw.600.0.11.2809209           VMware  VMwareCertified   2015-07-21 lsu-lsi-lsi-msgpt3-plugin      1.0.0-1vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 lsu-lsi-megaraid-sas-plugin    1.0.0-2vmw.600.0.11.2809209           VMware  VMwareCertified   2015-07-21 lsu-lsi-mpt2sas-plugin         1.0.0-1vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 lsu-lsi-mptsas-plugin          1.0.0-1vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 misc-cnic-register             1.78.75.v60.7-1vmw.600.0.0.2494585    VMware  VMwareCertified   2015-04-28 misc-drivers                   6.0.0-0.11.2809209                    VMware  VMwareCertified   2015-07-21 net-bnx2                       2.2.4f.v60.10-1vmw.600.0.0.2494585    VMware  VMwareCertified   2015-04-28 net-bnx2x                      1.78.80.v60.12-1vmw.600.0.0.2494585   VMware  VMwareCertified   2015-04-28 net-cnic                       1.78.76.v60.13-2vmw.600.0.0.2494585   VMware  VMwareCertified   2015-04-28 net-e1000                      8.0.3.1-5vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 net-e1000e                     2.5.4-6vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 net-enic                       2.1.2.38-2vmw.600.0.0.2494585         VMware  VMwareCertified   2015-04-28 net-forcedeth                  0.61-2vmw.600.0.0.2494585             VMware  VMwareCertified   2015-04-28 net-igb                        5.0.5.1.1-5vmw.600.0.0.2494585        VMware  VMwareCertified   2015-04-28 net-ixgbe                      3.7.13.7.14iov-20vmw.600.0.0.2494585  VMware  VMwareCertified   2015-04-28 net-mlx4-core                  1.9.7.0-1vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 net-mlx4-en                    1.9.7.0-1vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 net-nx-nic                     5.0.621-5vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 net-tg3                        3.131d.v60.4-1vmw.600.0.0.2494585     VMware  VMwareCertified   2015-04-28 net-vmxnet3                    1.1.3.0-3vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 nmlx4-core                     3.0.0.0-1vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 nmlx4-en                       3.0.0.0-1vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 nmlx4-rdma                     3.0.0.0-1vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 nvme                           1.0e.0.35-1vmw.600.0.0.2494585        VMware  VMwareCertified   2015-04-28 ohci-usb-ohci                  1.0-3vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 qlnativefc                     2.0.12.0-5vmw.600.0.0.2494585         VMware  VMwareCertified   2015-04-28 rste                           2.0.2.0088-4vmw.600.0.0.2494585       VMware  VMwareCertified   2015-04-28 sata-ahci                      3.0-21vmw.600.0.11.2809209            VMware  VMwareCertified   2015-07-21 sata-ata-piix                  2.12-10vmw.600.0.0.2494585            VMware  VMwareCertified   2015-04-28 sata-sata-nv                   3.5-4vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 sata-sata-promise              2.12-3vmw.600.0.0.2494585             VMware  VMwareCertified   2015-04-28 sata-sata-sil24                1.1-1vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 sata-sata-sil                  2.3-4vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 sata-sata-svw                  2.3-3vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 scsi-aacraid                   1.1.5.1-9vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 scsi-adp94xx                   1.0.8.12-6vmw.600.0.0.2494585         VMware  VMwareCertified   2015-04-28 scsi-aic79xx                   3.1-5vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 scsi-bnx2fc                    1.78.78.v60.8-1vmw.600.0.0.2494585    VMware  VMwareCertified   2015-04-28 scsi-bnx2i                     2.78.76.v60.8-1vmw.600.0.11.2809209   VMware  VMwareCertified   2015-07-21 scsi-fnic                      1.5.0.45-3vmw.600.0.0.2494585         VMware  VMwareCertified   2015-04-28 scsi-hpsa                      6.0.0.44-4vmw.600.0.0.2494585         VMware  VMwareCertified   2015-04-28 scsi-ips                       7.12.05-4vmw.600.0.0.2494585          VMware  VMwareCertified   2015-04-28 scsi-megaraid-mbox             2.20.5.1-6vmw.600.0.0.2494585         VMware  VMwareCertified   2015-04-28 scsi-megaraid2                 2.00.4-9vmw.600.0.0.2494585           VMware  VMwareCertified   2015-04-28 scsi-mpt2sas                   19.00.00.00-1vmw.600.0.0.2494585      VMware  VMwareCertified   2015-04-28 scsi-mptsas                    4.23.01.00-9vmw.600.0.0.2494585       VMware  VMwareCertified   2015-04-28 scsi-mptspi                    4.23.01.00-9vmw.600.0.0.2494585       VMware  VMwareCertified   2015-04-28 scsi-qla4xxx                   5.01.03.2-7vmw.600.0.0.2494585        VMware  VMwareCertified   2015-04-28 uhci-usb-uhci                  1.0-3vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 vmware-esx-dvfilter-maclearn   1.00-1.00                             VMware  VMwareCertified   2015-05-12 xhci-xhci                      1.0-2vmw.600.0.0.2494585              VMware  VMwareCertified   2015-04-28 tools-light                    6.0.0-0.11.2809209                    VMware  VMwareCertified   2015-07-21 [root@intelserver:~ Verify that the scsi-megaraid-sas driver is installed prior to proceeding.  2).  To disable the lsi_mr3 driver do the following:  " esxcli system module set --enabled=false --module=lsi_mr3"   3).  Reboot After rebooting do: "esxcfg-scsidev -a"  to verify that megaraid_sas driver is assigned to your disk controller.   I don't know how ESXi decides the order of precedence if two or more drivers are applicable to a single hardware device, or if the install process of the new LSI driver is supposed to disable or remove the default lsi_mr3 driver and simply failed to do so.  I also don't know what's going to happen when I put on the next ESXi patch, specifically if the lsi_mr3 driver will once again take precedence.  If anyone knows how the driver install process is supposed to work in this situation please let me know.  I am happy though that I finally got this fixed as the server was seriously gimped by having the datastore become unaccessable for 5-10 seconds everytime a VM started or stopped, and the old driver on at least one occasion did something bad enough to fool the controller into thinking that one of the disks had gone bad and started a RAID resynch.   
I found some interesting log entries that did show the issue is locking, and I also see a whole bunch of scsi commands being retried and rejected or reset.  Unfortunately I'm not a scsi expert so... See more...
I found some interesting log entries that did show the issue is locking, and I also see a whole bunch of scsi commands being retried and rejected or reset.  Unfortunately I'm not a scsi expert so I can't easily decode what's going on here or why.   I'm attaching a link that shows the relevent portions of the vmkernel log and the hostd log.   The relevant time period starts at about 06:17:25 when I started VM SBS2008.  About 9  seconds later is when the lost access message shows in the hostd log, although meanwhile in the vmkernel log are a whole bunch of scsi commands hanging and being reset.   Maybe somebody more fluent in scsi protocol can give me some direction as to what's going on.   I'm still very skeptical that it's a hardware problem in that a disk is bad because of all the stuff I mentioned before, but maybe there is some sort of scsi command being issued here that causes the controller a problem.  https://drive.google.com/folderview?id=0B_1WZam8s_8BfllFLXNiUW9oOHZpS3lkWk1xNzhXQUppNFZ0THE1MTY2UDhpYm1fNXBRd1E&usp=sharing
Time for an update.  I bought a LSI 9361-8i controller and I bought the capacitor battery backup so that I could enable write caching.  Unfortunately this changed nothing.  I also updated ESXi to... See more...
Time for an update.  I bought a LSI 9361-8i controller and I bought the capacitor battery backup so that I could enable write caching.  Unfortunately this changed nothing.  I also updated ESXi to the July patch level and that changed nothing either.  I also tried the latest driver from LSI (which the ESXi patch process promptly replaced when I applied it), and that didn't do anything either.  I'm beginning to think this is some sort of software problem related to locking of the files, as this only happens when certain VMs start and stop, and only at the moment when they first start (before the console display starts), and when they stop and transition from running to inactive.  The two VMs that it always happens to are a Windows SBS 2008 VM and the VCenter Server appliance VM.   The only things I can see in common with those two is that they both have multiple VCPUs assigned to them and (and maybe this is important) they have quite a number of virtual disks in the configuration.  Somehow when these VMs start and stop it's causing all I/O to the datastore to stop such that the watchdog timer goes off and causes the lost access process to begin.  I actually think that whatever is being done is happening at the controller level (i.e. ESXi has issued some sort of command to the controller that is hanging things up) because when I had both SBS 2008 and the VCenter Server appliance on this machine at the same time and they both started at once, it caused a big enough problem that controller threw a disk error and started a rebuild, which happened a couple of times until I moved the VCenter Server VM to another machine.  I've sort of ruled out a hardware problem because the rebuild was occurring on different disks in the array and these are new SSD drives.  Also, there are never any errors or lost access messages if I download the files for both VMs from the server, like one would expect if there was a disk problem and it was having trouble reading data.  Also there are never any errors or lost access messages no matter how hard I stress the array with reads and writes.  It's only at VM startup and shutdown and only for certain VMs that this happens. I'm stumped at this point and my wallet has been drained from replacing parts.  Not a good situation
Did you ever get a resolution to this?  I'm having some issues with lost connectivity as well and have some of the same hardware as you.  However, in my case the problem seems to occur when I sta... See more...
Did you ever get a resolution to this?  I'm having some issues with lost connectivity as well and have some of the same hardware as you.  However, in my case the problem seems to occur when I start or stop certain VMs, rather than on a timed schedule.  I am also using a LSI Megaraid controller with SSD drives.   In my case the whole thing crashed on me at least once, and I was showing hardware errors in the Bios event log some of the time.  Here's a link to the thread: Lost access to local datastore I'm curious if there are anymore similarities between our two issues.
Without the battery the controller won't do cached writes, which I'm wondering if is somehow related to the behavior I'm seeing.  I wasn't aware that the other controller wouldn't work with ESXi ... See more...
Without the battery the controller won't do cached writes, which I'm wondering if is somehow related to the behavior I'm seeing.  I wasn't aware that the other controller wouldn't work with ESXi in RAID mode.  I'll have to do some more research on that.  I supposed the last resort would be to buy a controller card as I don't think there is an option to add a battery to the onboard LSI controller.  Unfortunately, this is all speculation and I would hate spending money on a new controller without knowing for sure that this whole line of reasoning is accurate.   I suppose I could also pay for an incident with VMWare (I have the Essentials product as I'm a consultant and don't have a whole datacenter full of equipment) and see if I can get them to work this out.
I checked into some more things and found that i have the April patch applied, not the May patch, although the description of the May patch indicates that it fixed just one bug which had nothing ... See more...
I checked into some more things and found that i have the April patch applied, not the May patch, although the description of the May patch indicates that it fixed just one bug which had nothing to do with my issue; so instead I went ahead and and upgraded the LSI driver to the current version, but it had no effect.  I still got the lost access message when I started up a couple of the VMs, and the RAID array still appears degraded to the ESXi esxcfg-scsidevs -l command even though the RAID Bios says it's fine. I'm beginning to suspect that there is some incompatibility here.  I wonder if they tried RAID 5 with this controller, and if that's the issue.  With this motherboard you have to buy an extra key dongle and attach it to the motherboard to enable RAID 5 on the LSI controller and I wonder if in their testing they didn't do that.  That's also true of the other Intel motherboard in the S2600CW series that comes with the attached LSI controller (the difference between the two boards is that my model also comes with 10gb NICs and the LSI controller where the other model with the LSI controller just has 1gb NICs). I'm trying to think of what happens at VM startup and shutdown that would cause this issue which doesn't happen at other times, as I don't get the message when I'm doing lots of I/Os to the controller from running VMs.  I've transferred gigabytes of data between VMs, both of which are hitting the same datastore, and I don't get the message, which leads me to believe it's note the rate of I/O's or even the rate of writes that's doing this.  The only thing I can think of is that I know VM startup and shutdown involves locking files that ESXi uses to know that a VM is active, and I'm wondering if ESXi does something different I/O wise when it's creating, manipulating, or deleting these lock files, such as trying to quiesce all I/O's to the datastore while this process is happening.   From what I can tell my controller doesn't do write caching because there is no battery option, but I didn't think that would be an issue with SSD drives.  Perhaps it is an issue if ESXi is doing something strange at VM startup and shutdown that holds up I/Os to the controller for a short period of time.  This is just my guess however. There is another RAID option on this motherboard, as I could use the software RAID capability present on all the S2600CW motherboards.  That would require re-cabling and probably a reformat of the disks, but if I can't get this figured out I may have to do it, as the configuration really isn't stable as is.  It also means I will have wasted my money in buying this version of the motherboard with the LSI controller.  <sigh> If you can think of anything else I'm certainly all ears, and I do thank you for your assistance. Here's the current info: [root@intelserver:~] esxcfg-scsidevs -l naa.6001e67ca647e0001cd1cdb8275eb90e    Device Type: Direct-Access    Size: 4878040 MB    Display Name: Intel Serial Attached SCSI Disk (naa.6001e67ca647e0001cd1cdb8275eb90e)    Multipath Plugin: NMP    Console Device: /vmfs/devices/disks/naa.6001e67ca647e0001cd1cdb8275eb90e    Devfs Path: /vmfs/devices/disks/naa.6001e67ca647e0001cd1cdb8275eb90e    Vendor: Intel     Model: RS3YC             Revis: 4.26    SCSI Level: 5  Is Pseudo: false Status: degraded    Is RDM Capable: true  Is Removable: false    Is Local: false Is SSD: true    Other Names:       vml.02000000006001e67ca647e0001cd1cdb8275eb90e525333594320    VAAI Status: unsupported [root@intelserver:~] vmkload_mod -s lsi_mr3 vmkload_mod module information input file: /usr/lib/vmware/vmkmod/lsi_mr3 Version: 6.606.10.00-1OEM.550.0.0.1391871 License: GPLv2 Required name-spaces:   com.vmware.vmkapi#v2_2_0_0 Parameters:   lb_pending_cmds: int     Change raid-1 load balancing outstanding threshold.Valid Values are 1-128. Default: 4   mfiDumpFailedCmd: int     Hex dump of failed command in driver log   max_sectors: int     Maximum number of sectors per IO command
Thanks for your assistance so far.  If I apply the above driver, you are saying that will automatically replace the existing driver?  Also, if I do that, what happens with the recovery option on ... See more...
Thanks for your assistance so far.  If I apply the above driver, you are saying that will automatically replace the existing driver?  Also, if I do that, what happens with the recovery option on the bootup screen?  If I understand things correctly, I can go back one patch or change by doing ALT-R during the boot sequence.  I was considering doing that to go back before the May patch to see if it still happens.  If I upgrade the driver will the recovery sequence on bootup just go back to before the driver, or is it tracking only the changes to the base ESXi code?   I'd like to keep the option of backing out the patch, although I suppose I could reapply the base ESXi 6 installation as long as it allows me through the update process to update to a prior version.  I haven't tried any of these things before so I'm not sure what the limitations are in the software update process.