<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>vmjoe Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>vmjoe Tracker</description>
    <pubDate>Tue, 21 Nov 2023 08:24:47 GMT</pubDate>
    <dc:date>2023-11-21T08:24:47Z</dc:date>
    <item>
      <title>Re: Moving disks to a different controller - does the DG survive?</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Moving-disks-to-a-different-controller-does-the-DG-survive/m-p/2961491#M15034</link>
      <description>&lt;P&gt;Thanks for you reply.&lt;/P&gt;&lt;P&gt;The hosts are of course designed as vSAN nodes, so the 430-8i is a dumb HBA, does not have cache and does not even offer RAID functionality:&lt;/P&gt;&lt;P&gt;"Non-RAID (JBOD mode) support for SAS and SATA HDDs and SSDs (RAID not supported)"&lt;BR /&gt;&lt;A href="https://lenovopress.lenovo.com/lp0649-thinksystem-430-8i-16i-internal-sas-hba" target="_blank" rel="noopener"&gt;https://lenovopress.lenovo.com/lp0649-thinksystem-430-8i-16i-internal-sas-hba&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Problem with actually testing it, we would have to purchase a second controller already, which is difficult or impossible in a large corporation. We can either buy them with all the SSDs for all servers, or not.&amp;nbsp;&lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@C2A029D8F56497C0B9F536A9C279C6DF/emoticons/1f644.png" alt=":face_with_rolling_eyes:" title=":face_with_rolling_eyes:" /&gt;&lt;/P&gt;&lt;P&gt;But your statement about donor servers makes me believe it would work. Actually, I remember something similar: in a two-become-one exercise, we consolidated SSDs from hosts with too small capacities into fewer hosts, and when a cache and capacity device 'accidentally' ended up together in the same target server, they were recognized as a disk group (with issues, like second capacity drive missing)...&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Anyway, I think we should go with the configuration that does &lt;EM&gt;not&lt;/EM&gt; need to move the disks that way. The options are: Two HBAs with two disk groups per HBA at 14 TB (3 capacity devices each), vs. only one DG per HBA with 28 TB (5 capacity devices each). Both configurations would be with the existing 750 GB cache device only. Price difference about 37,000 Euro...&lt;/P&gt;</description>
      <pubDate>Wed, 29 Mar 2023 08:32:22 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Moving-disks-to-a-different-controller-does-the-DG-survive/m-p/2961491#M15034</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2023-03-29T08:32:22Z</dc:date>
    </item>
    <item>
      <title>Moving disks to a different controller - does the DG survive?</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Moving-disks-to-a-different-controller-does-the-DG-survive/m-p/2961373#M15027</link>
      <description>&lt;P&gt;Hello&lt;/P&gt;&lt;P&gt;I'm planning a disk extension of a vSAN 7.0.3 (soon 8.0) cluster, and ended up with different theoretical options. One would involve the move of an entire disk group (one cache and two capacity SSDs) to a newly to-be-added controller (to keep disk groups and controllers aligned as one failure domain).&lt;/P&gt;&lt;P&gt;Question is: will the DG still be detected as present and intact, when connected via a different controller? (By the disk identifiers, or some vSAN signature?) Or would this move from one ThinkSystem 430-8i controller to an added identical one, destroy the DG?&lt;/P&gt;&lt;P&gt;I know I can evacuate DGs etc., but it takes time and increases the risk, time and involvement of local technicians significantly, so I would avoid it, and rather choose an option where the current DGs would be kept as-is, and just get extended and complemented by additional DGs.&lt;/P&gt;</description>
      <pubDate>Tue, 28 Mar 2023 15:51:56 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Moving-disks-to-a-different-controller-does-the-DG-survive/m-p/2961373#M15027</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2023-03-28T15:51:56Z</dc:date>
    </item>
    <item>
      <title>Re: VMware Tools 11.3.0 altering vmx configuration, causing incompatibility with older vmxnet3 drive</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/VMware-Tools-11-3-0-altering-vmx-configuration-causing/m-p/2871892#M278497</link>
      <description>&lt;P&gt;SR number sent. Also just had a follow-up call with support, I think the phenomenon is understood now, but not at all why it happens.&lt;/P&gt;</description>
      <pubDate>Thu, 14 Oct 2021 10:53:31 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/VMware-Tools-11-3-0-altering-vmx-configuration-causing/m-p/2871892#M278497</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2021-10-14T10:53:31Z</dc:date>
    </item>
    <item>
      <title>VMware Tools 11.3.0 altering vmx configuration, causing incompatibility with older vmxnet3 drivers</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/VMware-Tools-11-3-0-altering-vmx-configuration-causing/m-p/2871509#M278472</link>
      <description>&lt;P&gt;Hello&lt;/P&gt;&lt;P&gt;We were facing a problem reinstalling Windows VMs. For example VMs that were still installing fine a month ago, cannot be reinstalled via PXE boot now. After extensive debugging, I found the reason.&lt;/P&gt;&lt;P&gt;Once a VM gets VMware Tools installed (or upgraded to) version 11.3.0 (11360), the .vmx file of the VM gets an additional line: ethernet0.exposeLargeBAR = "TRUE" (at least if the virtual hardware version is 19; didn't see it happen on v15)&lt;/P&gt;&lt;P&gt;When such a VM gets booted with Windows Preinstallation Environment (WinPE) again for reinstallation, there's no network card (vmxnet3) available for that OS, because the driver is older and apparently incompatible with this exposeLargeBAR option (the vmxnet driver loads successfully, but no network card is recognized).&lt;/P&gt;&lt;P&gt;Once this line is removed, everything works again. Or if the vmxnet3 driver 1.9.2 gets manually loaded, it also gets detected.&lt;/P&gt;&lt;P&gt;I've opened a case with VMware GSS two weeks ago, but they even can't find "exposeLargeBAR" in their internal docs and knowledge bases! Google yields zero hits as well...&lt;/P&gt;&lt;P&gt;We also had freshly reinstalled Windows VMs fail at a later stage, when Windows was already running but still with version 10.3 of VMware Tools (that version is in our automated installation method and gets updated later), once the VM gets powered off and on, or even when it just got moved to another host (then the new config value "kicked in", apparently).&lt;/P&gt;&lt;P&gt;So if someone faces mysterious vmxnet3 connection losses, that's something to check (either in the .vmx, or via GUI: VM &amp;gt; Edit Settings &amp;gt; VM Options &amp;gt; Advanced &amp;gt; Edit Configuration Parameters. Removing the TRUE value and powering on the VM will remove the option.&lt;/P&gt;&lt;P&gt;Of course it doesn't happen if you revert a VM via snapshot, because along with the vmxnet3 driver version, also the .vmx config gets reverted. But if someone would restore a backup into a VM container that has been altered, the same situation can happen.&lt;/P&gt;</description>
      <pubDate>Tue, 12 Oct 2021 10:06:05 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/VMware-Tools-11-3-0-altering-vmx-configuration-causing/m-p/2871509#M278472</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2021-10-12T10:06:05Z</dc:date>
    </item>
    <item>
      <title>Re: ESXi 7.0U3 is out but has a known issue that sounds scary</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/ESXi-7-0U3-is-out-but-has-a-known-issue-that-sounds-scary/m-p/2871501#M278471</link>
      <description>&lt;P&gt;Hey, it's only "some", not all data that is lost&amp;nbsp;&lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@09DE7ADF49A7E8DF3ED7B58A02845D9E/emoticons/1f606.png" alt=":grinning_squinting_face:" title=":grinning_squinting_face:" /&gt;&lt;/P&gt;&lt;P&gt;Yeah better wait until this show up in the "Issues resolved" section. But I guess it's indeed "rare", otherwise it would be pulled. On the other hand, VMware is releasing a lot of crap recently, so you never know...&lt;/P&gt;</description>
      <pubDate>Tue, 12 Oct 2021 09:44:08 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/ESXi-7-0U3-is-out-but-has-a-known-issue-that-sounds-scary/m-p/2871501#M278471</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2021-10-12T09:44:08Z</dc:date>
    </item>
    <item>
      <title>Re: The host returns esxupdate error codes: -1. Check the Update Manager log files and esxupdate log</title>
      <link>https://communities.vmware.com/t5/Update-Manager-Discussions/The-host-returns-esxupdate-error-codes-1-Check-the-Update/m-p/2871327#M5731</link>
      <description>&lt;P&gt;VMware has royally f*ed this up, again. We not only have &lt;U&gt;this&lt;/U&gt; issue (and NO, no 'payload' error in esxupdate.log), but even more severe issues, even unrelated baselines are getting 'not compliant' once you remediate another one...&lt;/P&gt;&lt;P&gt;In two totally independent vCenter appliances (7.0.2 build&amp;nbsp;&lt;SPAN&gt;18455184).&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 11 Oct 2021 14:41:10 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Update-Manager-Discussions/The-host-returns-esxupdate-error-codes-1-Check-the-Update/m-p/2871327#M5731</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2021-10-11T14:41:10Z</dc:date>
    </item>
    <item>
      <title>Re: Datastore does not match current VM policy. Storage Fault has occurred</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Datastore-does-not-match-current-VM-policy-Storage-Fault-has/m-p/2860876#M13350</link>
      <description>&lt;P&gt;I re-created the cluster thrice (including wiping the disks, and moving hosts out of the cluster etc.), always ending up with the same situation: Performance Service is "enabled" on the vSAN Services pane, but not actually starting (fields Stats object health, Stats object UUID,&amp;nbsp;Stats object storage policy and Compliance status are not populating with values).&lt;/P&gt;&lt;P&gt;The reason was the&amp;nbsp;&lt;SPAN&gt;VMware vSphere Profile-Driven Storage Service in vCenter. Login to the vCSA VAMI page and restart the service. Wait a while and the Performance Service will be up and running, the problems disappear.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Alternatively, reboot vCenter (if you can afford to do so).&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Thu, 05 Aug 2021 14:03:40 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Datastore-does-not-match-current-VM-policy-Storage-Fault-has/m-p/2860876#M13350</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2021-08-05T14:03:40Z</dc:date>
    </item>
    <item>
      <title>Re: Datastore does not match current VM policy. Storage Fault has occurred</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Datastore-does-not-match-current-VM-policy-Storage-Fault-has/m-p/2860657#M13348</link>
      <description>&lt;P&gt;Same issue here &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@8D3AC78033E090809829B1C8262B7619/emoticons/1f61e.png" alt=":disappointed_face:" title=":disappointed_face:" /&gt;&lt;/P&gt;&lt;P&gt;6 fresh ESXi 7.0.2 hosts, two disk groups each (all-flash), have a RAID-6 policy in place which does not work properly. The vSAN datastore is even listed as incompatible for a RAID-1 policy. No fault domains configured (tested it also with 6 FDs configured, but deleted them again).&lt;/P&gt;&lt;P&gt;Oddly enough, when I create a VM or move the vCLS VMs onto vSAN, there's a warning about "Datastore does not match current policy", but it allows to do so, and under Skyline Health &amp;gt; Virtual Objects they are healthy with their RAID-6 policy!!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 04 Aug 2021 07:33:51 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Datastore-does-not-match-current-VM-policy-Storage-Fault-has/m-p/2860657#M13348</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2021-08-04T07:33:51Z</dc:date>
    </item>
    <item>
      <title>Kickstart installation - how to define disk</title>
      <link>https://communities.vmware.com/t5/vSphere-Upgrade-Install/Kickstart-installation-how-to-define-disk/m-p/2838123#M33258</link>
      <description>&lt;P&gt;Hello&lt;/P&gt;&lt;P&gt;I need to install 150+ vSAN hosts and therefore set up PXE boot with a kickstart script. We have hardware from two vendors. On the Huawei hosts I see only the disk where the ESXi installation should go, so the ks parameter &lt;FONT face="courier new,courier"&gt;install --firstdisk&lt;/FONT&gt; works. This is because the second controller with the vSAN disks is not yet configured...&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;On the Lenovo hosts however, by default I see also the vSAN cache and capacity disks, and the RAID controller with the disk for ESXi is listed as the last one... so I can't use "firstdisk". (The same applies to the Huawei hosts once the controller has been set to JBOD mode for vSAN)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;According to the vSphere product documentation I shall be able to address the disks with their device path:&lt;FONT face="courier new,courier"&gt; --disk=/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.upgrade.doc/GUID-61A14EBB-5CF3-43EE-87EF-DB8EC6D83698.html" target="_blank"&gt;https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.upgrade.doc/GUID-61A14EBB-5CF3-43EE-87EF-DB8EC6D83698.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;But this does not work (at least not with ESXi 7.0.2), only the device names (naa.1234567890) are available it seems. The kickstart script stops with the error &lt;FONT face="courier new,courier"&gt;"... install --disk= specified, but drive "/vmfs/devices/disks/mpx.vmhba3:C2:T0:L0" was not found on the system. The available disk(s) are: naa.1234567890" &lt;/FONT&gt;etc.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Even on an installed host, there are no mpx or vmhba devices under /vmfs/devices/disks, only those random naa numbers. How the hell can I make a ks script that finds the correct disk to install?! &lt;FONT face="courier new,courier"&gt;--seventhdisk&lt;/FONT&gt; would be what I need in this case...&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 25 Mar 2021 12:13:19 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Upgrade-Install/Kickstart-installation-how-to-define-disk/m-p/2838123#M33258</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2021-03-25T12:13:19Z</dc:date>
    </item>
    <item>
      <title>Re: partedUtil : Error: Read-only file system during write</title>
      <link>https://communities.vmware.com/t5/Storage-Performance/partedUtil-Error-Read-only-file-system-during-write/m-p/896825#M5195</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Old, old thread, I know. But I spent some hours with the same problem and finally found the solution, so in case someone finds this thread by searching...&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The error with &lt;SPAN style="color: #000000; font-family: 'Courier New';"&gt;partedUtil setptbl &lt;/SPAN&gt;resulting in&lt;SPAN style="color: #000000; font-family: 'Courier New';"&gt; &lt;SPAN style="color: #000000; font-family: 'Courier New';"&gt;SetPtableGpt: Unable to commit to disk&lt;/SPAN&gt;&lt;/SPAN&gt; is "simple":&amp;nbsp; setptbl seems to require to specify the ENTIRE partition layout, so &lt;SPAN style="color: #3d3d3d;"&gt;all existing&lt;/SPAN&gt; partitions with all their starting end ending sectors etc., plus the one you want to create.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;But, luckily, that is not necessary if you just need to &lt;EM&gt;add&lt;/EM&gt; a partition at the end (or probably also in between, if there's space). Just use&lt;SPAN style="color: #000000; font-family: arial, helvetica, sans-serif;"&gt; &lt;SPAN style="color: #000000; font-family: 'Courier New';"&gt;partedUtil add&lt;/SPAN&gt;&lt;/SPAN&gt; instead and it should work!&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 25 Sep 2020 12:30:28 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Storage-Performance/partedUtil-Error-Read-only-file-system-during-write/m-p/896825#M5195</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2020-09-25T12:30:28Z</dc:date>
    </item>
    <item>
      <title>Re: "Unable to query vSphere health information" and "Unable to query vSAN health information" after certificate replacement - VCSA 6.7U2</title>
      <link>https://communities.vmware.com/t5/vCenter-Server-Discussions/quot-Unable-to-query-vSphere-health-information-quot-and-quot/m-p/2256980#M73979</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;For me, this error is always fixed by just logging out and logging in again... (before, I was always deleting cookies, which also logs me out, but not even that seems necessary).&lt;/P&gt;&lt;P&gt;Latest vCenter 7, super annoying. Also tags are "disappearing" (just not shown), but they're there if I use another PC/browser/delete cookies....&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 17 Jul 2020 08:25:46 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vCenter-Server-Discussions/quot-Unable-to-query-vSphere-health-information-quot-and-quot/m-p/2256980#M73979</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2020-07-17T08:25:46Z</dc:date>
    </item>
    <item>
      <title>Re: Which driver to choose | ESXi 6.5 Elxnet</title>
      <link>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Which-driver-to-choose-ESXi-6-5-Elxnet/m-p/1382313#M13943</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Since I have a similiar issue: check the supported driver version for the specific card!&lt;/P&gt;&lt;P&gt;&lt;A href="https://www.vmware.com/resources/compatibility/search.php" title="https://www.vmware.com/resources/compatibility/search.php"&gt;VMware Compatibility Guide - System Search&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In &lt;A _jive_internal="true" href="https://communities.vmware.com/thread/608045"&gt;my case&lt;/A&gt; (HPE FlexFabric 554M card) I had to use an "older" driver (at least by version number); the latest driver is unstable (and not listed on VMware compatibility page).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If the 12* driver is listed, I would try it (the 11* is maybe a hotfix for an older driver branch).&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 26 Mar 2019 13:15:04 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Which-driver-to-choose-ESXi-6-5-Elxnet/m-p/1382313#M13943</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2019-03-26T13:15:04Z</dc:date>
    </item>
    <item>
      <title>Issue with elxnet driver from HPE driver bundle and VUM</title>
      <link>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Issue-with-elxnet-driver-from-HPE-driver-bundle-and-VUM/m-p/1843075#M20446</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have an issue with VMware Update Manager and would like to know how you would handle this situation:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;HPE BL460c Gen8 hosts equipped with FlexFabric 10Gb 2-port 554M adapter running ESXi 6.0U3 (6.5U2 would be supported, but would not change the issue).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The card itself is supported by HPE with Gen8 blades:&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-external-small" href="https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c03215797" rel="nofollow"&gt;https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c03215797&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The 554M card is supported by VMware with driver elxnet version 11.1.183.654&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-external-small" href="https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&amp;amp;productid=21423&amp;amp;vcl=true" rel="nofollow"&gt;https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&amp;amp;productid=21423&amp;amp;vcl=true&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;BUT - if you use HPE Depot &lt;/SPAN&gt;&lt;A class="jive-link-external-small" href="http://vibsdepot.hpe.com/index-drv.xml" rel="nofollow"&gt;http://vibsdepot.hpe.com/index-drv.xml&lt;/A&gt;&lt;SPAN&gt; in Update Manager, it deploys hpe-driver-bundle-600.10.3.6 which contains a NEWER driver (elxnet 12.0.1115.0), which is not supported, and it crashes the hosts after some time (about 90 days in my experience). (Also previous bundles already contain the newer/unsupported elxnet driver.)&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We encountered the problem described here ("UE detected!!"):&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Lost network connectivity with Emulex Card [...]&lt;/P&gt;&lt;P&gt;&lt;A class="jive-link-external-small" href="https://kb.vmware.com/s/article/50106632?lang=en_US" rel="nofollow"&gt;https://kb.vmware.com/s/article/50106632?lang=en_US&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I now manually downgraded the elxnet drivers and so far so good (although the problem previously occured only after about 90 days uptime). But now the hosts show up as "not up to date" and the entire HPE driver bundle is marked for installation. Since the bundle also contains "good" drivers like hpsa etc., I don't want to remove it entirely from the repository...&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Is there a way to declare the older elxnet driver as the most current, or downgrade it in the bundle, or...?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 26 Mar 2019 13:08:54 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Issue-with-elxnet-driver-from-HPE-driver-bundle-and-VUM/m-p/1843075#M20446</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2019-03-26T13:08:54Z</dc:date>
    </item>
    <item>
      <title>Re: Petition VMware to Open Source ESXi Thick Client</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Petition-VMware-to-Open-Source-ESXi-Thick-Client/m-p/1404276#M134409</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Although this post is nine months old now and only received 21 likes (!?), I totally support it.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We will stay on vSphere 6.0 until they deliver something useable. We practically skipped the Flash hell and are now trying the HTML5 Fling. But 99 % of the time we're still using the C# client, it works SO MUCH better than anything else.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;And we're talking about an enterprise environment with 200+ hosts and 2,700+ VMs, 10.5 THz CPU and 84.3 TB memory. I don't know how many millions we're paying to VMware... they SHOULD LISTEN.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 27 Mar 2018 16:11:13 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Petition-VMware-to-Open-Source-ESXi-Thick-Client/m-p/1404276#M134409</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2018-03-27T16:11:13Z</dc:date>
    </item>
    <item>
      <title>Re: Wrong error "vMotion is not enabled on the host"</title>
      <link>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Wrong-error-quot-vMotion-is-not-enabled-on-the-host-quot/m-p/451964#M943</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I updated vSphere Client to the latest build 6855219 (previous attempts to do so failed because of the dreaded hcmon.sys error), but these vMotion problem remains.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It's so sad that VMware dropped the best client for their product. :smileycry: We'll definitely not use Web Client (the Flash shit), but skip it entirely and try HTML5 client instead...&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 21 Mar 2018 10:32:24 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Wrong-error-quot-vMotion-is-not-enabled-on-the-host-quot/m-p/451964#M943</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2018-03-21T10:32:24Z</dc:date>
    </item>
    <item>
      <title>Re: Wrong error "vMotion is not enabled on the host"</title>
      <link>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Wrong-error-quot-vMotion-is-not-enabled-on-the-host-quot/m-p/451962#M941</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;In my case, it affects &lt;SPAN style="text-decoration: underline;"&gt;all&lt;/SPAN&gt; VMs on the host (and most or all hosts in a cluster), as the vCenter or vSphere Client "thinks", vMotion is not enabled on the &lt;SPAN style="text-decoration: underline;"&gt;host&lt;/SPAN&gt;. It't nothing on VM level. Plus it always reapperas after the described workaround.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;It's just good that DRS still works... :smileyshocked:&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 15 Mar 2018 12:15:13 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Wrong-error-quot-vMotion-is-not-enabled-on-the-host-quot/m-p/451962#M941</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2018-03-15T12:15:13Z</dc:date>
    </item>
    <item>
      <title>Wrong error "vMotion is not enabled on the host"</title>
      <link>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Wrong-error-quot-vMotion-is-not-enabled-on-the-host-quot/m-p/451959#M938</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;We have a strange behaviour in one of our vCenters (6.0 U3d on Windows 2012R2 server).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When manually starting a vMotion migration, the option "Change host" is greyed out with the mesage "vMotion is not enabled on the host of the Virtual Machine". But vMotion &lt;SPAN style="text-decoration: underline;"&gt;&lt;STRONG&gt;IS&lt;/STRONG&gt;&lt;/SPAN&gt; enabled on the host... and correctly configured... and licensed... and it works if DRS needs to do a migration!&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;My workaround is to disable vMotion on the host on the relevant VMKernel interface and enable it again, then it works for some hours or so... until it returns to the above error message.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Someone else described the exact same thing here (without solution, just the same workaround):&lt;/P&gt;&lt;P&gt;&lt;A href="http://noor2122.blogspot.de/2017/12/fixing-error-vmotion-is-not-enabled-on.html" title="http://noor2122.blogspot.de/2017/12/fixing-error-vmotion-is-not-enabled-on.html"&gt;Information Sharing: Fixing the error "vMotion is not enabled on the host of the Virtual Machine"&lt;/A&gt; &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;- This happens on all (ca. &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@482170C6F13186AA4746798ECA69B77C/emoticons/1f60e.png" alt=":smiling_face_with_sunglasses:" title=":smiling_face_with_sunglasses:" /&gt; clusters in the datacenter&lt;/P&gt;&lt;P&gt;- It affects all VMs on the host&lt;/P&gt;&lt;P&gt;- It only affects a host as "vMotion source" (migrating off the host), the same host works if it is the vMotion target &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@90D223CDF4C4491D7DFF693BB5C76865/emoticons/1f609.png" alt=":winking_face:" title=":winking_face:" /&gt;&lt;/P&gt;&lt;P&gt;- A host that was a "target" of a vMotion, suddenly also works for outgoing vMotions... :smileyconfused:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I might be wrong, but I vaguely link the problem to an incident where we accidentally exceeded the Hosts per Cluster Configuration Maximum (64 hosts). The cluster had 66 or 67 hosts before we split it in two clusters... (that Configration Maximum is not a hardcoded limit...! :smileyangry:).&lt;/P&gt;&lt;P&gt;Now I just tried it with the HTML5 Client (Fling) and the phenomenon is not present there! So it's a vSphere Client (C#) only problem? :smileyangry:&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 14 Mar 2018 18:25:45 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Wrong-error-quot-vMotion-is-not-enabled-on-the-host-quot/m-p/451959#M938</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2018-03-14T18:25:45Z</dc:date>
    </item>
    <item>
      <title>Re: "Remote access for ESXi local user account 'root'  has been locked for 120 seconds..."</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/quot-Remote-access-for-ESXi-local-user-account-root-has-been/m-p/961554#M84642</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I have the same problem, and can't find any log that contains the SOURCE of that failed logins! :smileyshocked:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;vobd.log only contains the message "Remote access for ESXi local user account 'root' has been locked for 120 seconds" over and over, but no log file seems to have the source IP... how is it possible to find the problem?!&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 13 Mar 2018 14:30:58 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/quot-Remote-access-for-ESXi-local-user-account-root-has-been/m-p/961554#M84642</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2018-03-13T14:30:58Z</dc:date>
    </item>
    <item>
      <title>Re: vCenter permissions are "temporarily forgotten" upon reboot</title>
      <link>https://communities.vmware.com/t5/VMware-vCenter-Discussions/vCenter-permissions-are-quot-temporarily-forgotten-quot-upon/m-p/445555#M3282</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I think you're on the right track... it's a fairly large AD. The resource domain, where the vCenter server is located: 7,500 groups and 10k+ (technical) users, user domain (trusted): 46k+ users and 115k+ groups... plus 40 other domains which are not used in vCenter. :smileyshocked:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Since the problem emerged some months ago, maybe a certain "threshold" of users/groups was exceeded.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When I seleect a domain in the permissiosn dialogue, it takes like 7 seconds until users and groups are listed... that's now on the weekend, it might be a bit slower during weekdays.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Can there anything be done to automatically "re-trigger" that AD object fetching at server startup (instead of manually adding a permission, which 'solves' the problem only until the next reboot)? Delayed start of a certain service maybe?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 03 Mar 2018 17:49:49 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vCenter-Discussions/vCenter-permissions-are-quot-temporarily-forgotten-quot-upon/m-p/445555#M3282</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2018-03-03T17:49:49Z</dc:date>
    </item>
    <item>
      <title>vCenter permissions are "temporarily forgotten" upon reboot</title>
      <link>https://communities.vmware.com/t5/VMware-vCenter-Discussions/vCenter-permissions-are-quot-temporarily-forgotten-quot-upon/m-p/445553#M3280</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have an odd problem with vCenter server (current version: 6.0U3d, build 7462484 - but it happens since some previous v6 builds).&lt;/P&gt;&lt;P&gt;vCenter and all it components runs on a single Windows server in a large AD domain. It has been upgraded several times since some v5 release.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When I reboot the vCenter server, most permissions are "temporarily forgotten". I myself can still login, because I'm member of VSPHERE.LOCAL\Administrators.&lt;/P&gt;&lt;P&gt;However, all accounts that have permissions set one level lower (a folder containing datacenters) cannot, because all these permissions are somehow "gone".&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;But now the odd thing: Once I grant one single account a permission, all the others will suddenly show up!&lt;/P&gt;&lt;P&gt;Maybe I should take a video of this... before you call me crazy or something. &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@90D223CDF4C4491D7DFF693BB5C76865/emoticons/1f609.png" alt=":winking_face:" title=":winking_face:" /&gt;&lt;/P&gt;&lt;P&gt;All 2-3 dozen permissions will be "restored" in a matter of a few seconds... I literally can see them "flowing in" in vSphere Client.&lt;/P&gt;&lt;P&gt;(The permissions are set mainly for AD user accounts, but also for an AD group.)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have the same phenomenon on two separate vCenter instances (production and pre-production).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Any ideas?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;-- &lt;/P&gt;&lt;P&gt;Johannes&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 28 Feb 2018 18:45:13 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vCenter-Discussions/vCenter-permissions-are-quot-temporarily-forgotten-quot-upon/m-p/445553#M3280</guid>
      <dc:creator>vmjoe</dc:creator>
      <dc:date>2018-02-28T18:45:13Z</dc:date>
    </item>
  </channel>
</rss>

