<?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>PatrickDLong Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>PatrickDLong Tracker</description>
    <pubDate>Sat, 25 Nov 2023 06:44:45 GMT</pubDate>
    <dc:date>2023-11-25T06:44:45Z</dc:date>
    <item>
      <title>Re: network issue after upgrade to ESXi 7.0 Update 3l</title>
      <link>https://communities.vmware.com/t5/vSphere-Upgrade-Install/network-issue-after-upgrade-to-ESXi-7-0-Update-3l/m-p/2966718#M34621</link>
      <description>&lt;P&gt;This issue (as well as the ntg3 driver issue) is fixed in ESXi 7.0 Update 3m build-21686933 released TODAY&amp;nbsp;2023-05-03&lt;/P&gt;&lt;P&gt;From:&lt;BR /&gt;&lt;A href="https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3m-release-notes.html" target="_blank" rel="noopener"&gt;https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3m-release-notes.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;PR&amp;nbsp;3164897:&amp;nbsp;After an upgrade to ESXi 7.0 Update 3l, some ESXi hosts and virtual machines connected to virtual switches might lose network&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;After an upgrade to ESXi 7.0 Update 3l, some ESXi hosts, their VMs, and other VMkernel ports, such as ports used by vSAN and&amp;nbsp;vSphere Replication, which are connected to virtual switches, might lose connectivity due to an unexpected change in the NIC teaming policy. For example, the teaming policy on a portgroup might change to&amp;nbsp;&lt;STRONG&gt;Route Based on Originating Virtual Port&amp;nbsp;&lt;/STRONG&gt;from&amp;nbsp;&lt;STRONG&gt;Route Based on IP Hash&lt;/STRONG&gt;. As a result, such a portgroup might lose network&amp;nbsp;connectivity&amp;nbsp;and some ESXi hosts and their VMs become inaccessible. &amp;nbsp;&lt;/P&gt;&lt;P&gt;AND&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;PR 3182870: After upgrading the ntg3 driver to version 4.1.9.0-4vmw, Broadcom NICs with fiber physical connectivity might lose network&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Changes in the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;ntg3&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;driver version&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;4.1.9.0-4vmw&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;might cause link issues for the fiber physical layer and connectivity on some NICs, such as Broadcom 1Gb, fails to come up.&lt;/P&gt;&lt;P&gt;This issue is resolved in this release. ESXi 7.0 Update 3m provides&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;ntg3&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;driver version&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;4.1.9.0-5vmw. The fix also adds a module parameter,&amp;nbsp;fifoElastic, which you can enable in case of jumbo frame drops in certain Dell switches. To enable the parameter, use&amp;nbsp;the following command:&lt;BR /&gt;esxcli system module parameters set -p 'fifoElastic=1' -m ntg3&lt;/P&gt;&lt;P&gt;If you are already experiencing this problem with Teaming and Failover load balancing due to applying 7.0 U3l, I do not believe that applying new release 7.0 U3m will revert any now-incorrect teaming policy back to what it was prior to your application of 7.0 U3l - you will likely need to do that manually. But honestly I have not yet applied U3m so I cannot say for sure.&lt;/P&gt;</description>
      <pubDate>Thu, 04 May 2023 00:02:51 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Upgrade-Install/network-issue-after-upgrade-to-ESXi-7-0-Update-3l/m-p/2966718#M34621</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2023-05-04T00:02:51Z</dc:date>
    </item>
    <item>
      <title>Re: Upgrade to VMware ESXi, 7.0.3, 21424296 breaks teaming/changes virtual switch settings</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Upgrade-to-VMware-ESXi-7-0-3-21424296-breaks-teaming-changes/m-p/2966704#M287944</link>
      <description>&lt;P&gt;This issue is fixed in ESXi 7.0 Update 3m build-21686933 released TODAY&amp;nbsp;2023-05-03&lt;BR /&gt;&lt;A href="https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3m-release-notes.html" target="_blank"&gt;https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3m-release-notes.html&lt;/A&gt;&lt;BR /&gt;PR 3164897: After an upgrade to ESXi 7.0 Update 3l, some ESXi hosts and virtual machines connected to virtual switches might lose network&lt;BR /&gt;After an upgrade to ESXi 7.0 Update 3l, some ESXi hosts, their VMs, and other VMkernel ports, such as ports used by vSAN and vSphere Replication, which are connected to virtual switches, might lose connectivity due to an unexpected change in the NIC teaming policy. For example, the teaming policy on a portgroup might change to Route Based on Originating Virtual Port from Route Based on IP Hash. As a result, such a portgroup might lose network connectivity and some ESXi hosts and their VMs become inaccessible.&lt;/P&gt;&lt;P&gt;If you are already experiencing this problem, I do not believe that applying new release 7.0 U3m will revert any now-incorrect teaming policy back to what it was prior to your application of 7.0 U3l - you will likely need to do that manually. But honestly I have not yet applied U3m so I cannot say for sure.&lt;/P&gt;</description>
      <pubDate>Wed, 03 May 2023 20:45:21 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Upgrade-to-VMware-ESXi-7-0-3-21424296-breaks-teaming-changes/m-p/2966704#M287944</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2023-05-03T20:45:21Z</dc:date>
    </item>
    <item>
      <title>Re: esxi update and load balancing settings</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/esxi-update-and-load-balancing-settings/m-p/2966700#M287943</link>
      <description>&lt;P&gt;This issue is fixed in ESXi 7.0 Update 3m build-21686933 released TODAY 2023-05-03&lt;BR /&gt;&lt;A href="https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3m-release-notes.html" target="_blank"&gt;https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3m-release-notes.html&lt;/A&gt;&lt;BR /&gt;PR 3164897: After an upgrade to ESXi 7.0 Update 3l, some ESXi hosts and virtual machines connected to virtual switches might lose network&lt;BR /&gt;After an upgrade to ESXi 7.0 Update 3l, some ESXi hosts, their VMs, and other VMkernel ports, such as ports used by vSAN and vSphere Replication, which are connected to virtual switches, might lose connectivity due to an unexpected change in the NIC teaming policy. For example, the teaming policy on a portgroup might change to Route Based on Originating Virtual Port from Route Based on IP Hash. As a result, such a portgroup might lose network connectivity and some ESXi hosts and their VMs become inaccessible.&lt;/P&gt;&lt;P&gt;If you are already experiencing this problem, I do not believe that applying new release 7.0 U3m will revert any now-incorrect teaming policy back to what it was prior to your application of 7.0 U3l - you will likely need to do that manually. But honestly I have not yet applied U3m so I cannot say for sure.&lt;/P&gt;</description>
      <pubDate>Wed, 03 May 2023 20:25:55 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/esxi-update-and-load-balancing-settings/m-p/2966700#M287943</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2023-05-03T20:25:55Z</dc:date>
    </item>
    <item>
      <title>Re: ESXI 7.0  and Storage Array FC Issue</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/ESXI-7-0-and-Storage-Array-FC-Issue/m-p/2965330#M287796</link>
      <description>&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5252780"&gt;@Msalvatore&lt;/a&gt;&amp;nbsp;Glad your solution was a simple one with a failed cable.&amp;nbsp; My recommendations to update the firmware of all components and update ESXi build still stands &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@677206E94727C39F3BB2721E5A55F2C1/emoticons/1f609.png" alt=":winking_face:" title=":winking_face:" /&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 24 Apr 2023 16:29:12 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/ESXI-7-0-and-Storage-Array-FC-Issue/m-p/2965330#M287796</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2023-04-24T16:29:12Z</dc:date>
    </item>
    <item>
      <title>Re: Storage is lost in ESXi</title>
      <link>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Storage-is-lost-in-ESXi/m-p/2965156#M45092</link>
      <description>&lt;P&gt;Is usbarbitrator running?&lt;STRONG&gt;&amp;nbsp;&amp;nbsp;/etc/init.d/usbarbitrator status&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;This service should be disabled if you are using USB storage as a datastore.&lt;/P&gt;&lt;P&gt;#stop the service if running&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;/etc/init.d/usbarbitrator stop&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Disable the service from running on startup:&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;chkconfig usbarbitrator off&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;then reboot and see if the storage is detected.&amp;nbsp; If not, you you can try to rescan for the storage by issuing:&amp;nbsp; e&lt;STRONG&gt;sxcfg-rescan -d vmhba32&amp;nbsp;&lt;/STRONG&gt; &amp;nbsp; a few times until it completes without error, then issue&amp;nbsp; &lt;STRONG&gt;esxcfg-rescan -a vmhba32&lt;/STRONG&gt;&amp;nbsp; &amp;nbsp;.&lt;/P&gt;&lt;P&gt;What version and build of ESXi are you running, and is this an external USB-connected disk device, or a USB stick?&amp;nbsp; Lastly, as I'm sure you already know,&amp;nbsp;VMFS on USB is NOT officially supported by VMware. although it is not an uncommon practice.&amp;nbsp; Never, ever do this in production or with data you cannot afford to lose &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@677206E94727C39F3BB2721E5A55F2C1/emoticons/1f609.png" alt=":winking_face:" title=":winking_face:" /&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sat, 22 Apr 2023 13:43:17 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSphere-Discussions/Storage-is-lost-in-ESXi/m-p/2965156#M45092</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2023-04-22T13:43:17Z</dc:date>
    </item>
    <item>
      <title>Re: ESXI 7.0  and Storage Array FC Issue</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/ESXI-7-0-and-Storage-Array-FC-Issue/m-p/2964968#M287740</link>
      <description>&lt;P&gt;The&lt;A href="https://support.hpe.com/connect/s/softwaredetails?softwareId=MTX_c366f48bfba54dfca7bb8ef5a7" target="_self"&gt; latest firmware for that HBA&lt;/A&gt; is:&lt;/P&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;TABLE border="0" cellspacing="0" cellpadding="0"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD&gt;HPE SN1100Q 16Gb 2P FC HBA&lt;/TD&gt;&lt;TD&gt;2.00.01&lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;P&gt;iLo is already at latest 2.81, but I would run the &lt;A href="https://support.hpe.com/connect/s/softwaredetails?softwareId=MTX_50b300127e24428582ca72564a" target="_self"&gt;latest Gen10 SPP&lt;/A&gt; to update all other firmware including BIOS.&lt;/P&gt;&lt;P&gt;Also, I would not under any circumstances run any version of ESXi 7.x lower than 7.0.3c, and preferably 7.0.3i,j,k, or l.&lt;/P&gt;&lt;P&gt;Use the latest HPE custom image for ProLiant linked &lt;A href="https://www.hpe.com/us/en/servers/hpe-esxi.html" target="_self"&gt;here , it is&amp;nbsp;VMware-ESXi-7.0.3-21424296-HPE-703.0.0.11.3.0.5-Apr2023.iso&lt;/A&gt; which is the absolute latest released build of ESXi 7.0.3 codebase, ESXi 7.0 Update 3l released 2023-03-30&lt;/P&gt;&lt;P&gt;I'm not sure if this will fix your issue, but this will allow you to rule out old firmware/drivers.&lt;/P&gt;</description>
      <pubDate>Fri, 21 Apr 2023 02:18:00 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/ESXI-7-0-and-Storage-Array-FC-Issue/m-p/2964968#M287740</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2023-04-21T02:18:00Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2929996#M283824</link>
      <description>&lt;P&gt;AFAIK, vm tool version is only checked against the ProductLocker version on these two events:&amp;nbsp; 1) the vm is v-motioned to a different host that also has the new value, or 2) you restart mgmt agents on the current host.&amp;nbsp; Naturally a host reboot would fulfill #2, but since you are not on 7.03uf your setting will not be preserved across reboots, so you would need to set it manually after the host comes up from its reboot BEFORE moving any vm's back to this host.&amp;nbsp; Probably easiest just to restart mgmt agents per &lt;A href="https://kb.vmware.com/s/article/1003490" target="_blank"&gt;https://kb.vmware.com/s/article/1003490&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Oh, and upgrade to 7.0u3f (or preferably7.0.3g build-20328353) ASAP and be done with this giant headache.&lt;/P&gt;</description>
      <pubDate>Wed, 21 Sep 2022 20:53:53 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2929996#M283824</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-09-21T20:53:53Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2918549#M282799</link>
      <description>&lt;P&gt;I've updated four hosts and my custom productLocker location on shared vmfs datastore was preserved on each host after reboot.&amp;nbsp; Can confirm this issue has been FIXED!&lt;/P&gt;</description>
      <pubDate>Wed, 13 Jul 2022 14:48:11 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2918549#M282799</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-07-13T14:48:11Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2918537#M282798</link>
      <description>&lt;P&gt;No sooner do I post the above than I see that 7.0 U3f is now released... and it includes this fix!!!&amp;nbsp; I will be patching a few hosts today and will report results.&lt;/P&gt;&lt;P&gt;&lt;A title="https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3f-release-notes.html" href="https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3f-release-notes.html" target="_blank" rel="noopener noreferrer"&gt;https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3f-release-notes.html&lt;/A&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;STRONG&gt;PR 2964856: Path to the /productLocker directory on a datastore truncates after patching ESXi 7.x&lt;/STRONG&gt;&lt;P&gt;After the first upgrade or update of your system to ESXi 7.x, with each consecutive update, also called a patch, you might see a truncation in the path to the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;/productLocker&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;directory on a datastore. For example, if your first patch on ESXi 7.x is from 7.0 Update 2 to 7.0 Update 3, the path to the&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;/productLocker&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;directory originally is similar to&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;/vmfs/volumes/xxx/VMware-Tools/productLocker/. However, for each consecutive patch, for example from 7.0 Update 3 to 7.0 Update 3c, the path becomes similar to&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;/VMware-Tools/productLocker/.&lt;/P&gt;&lt;P&gt;This issue is resolved in this release.&lt;/P&gt;&lt;/LI&gt;&lt;/UL&gt;</description>
      <pubDate>Wed, 13 Jul 2022 13:11:23 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2918537#M282798</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-07-13T13:11:23Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2918464#M282788</link>
      <description>&lt;P&gt;This fix did not make it into ESXi 7.0 U3e - or at least I should say I am still experiencing this issue when upgrading 7.0 U3d to ESXi 7.0 U3e via VUM.&amp;nbsp; Perhaps Support gave me incorrect information, or perhaps this fix is in there, but only protects ProductLocker from reverting on updates applied AFTER installing 7.0 U3e.&amp;nbsp; I'll report back as soon as I apply any post-U3e patches.&lt;/P&gt;</description>
      <pubDate>Tue, 12 Jul 2022 23:39:54 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2918464#M282788</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-07-12T23:39:54Z</dc:date>
    </item>
    <item>
      <title>Re: NTP: Why will my host NOT sync time to the NTP source</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/NTP-Why-will-my-host-NOT-sync-time-to-the-NTP-source/m-p/2918463#M282787</link>
      <description>&lt;P&gt;Anybody know how to REMOVE a line from ntp.conf in ESXi 7.0 U3?&amp;nbsp; I saw conflicting guidance about which tos maxdist value to use (KB 86255 indicates to use a maxdist of 15 while KB 87488 and 1035833 both indicate a maxdist value of 30)&amp;nbsp; and I ended up accidentally running the process twice and injecting two lines with different values.&amp;nbsp; Now my ntp.conf file includes TWO tos maxdist lines as shown:&lt;/P&gt;&lt;P&gt;[root@hostname:~] cat /etc/ntp.conf&lt;BR /&gt;# Do not edit this file, config store overwites it&lt;BR /&gt;restrict default nomodify notrap nopeer noquery&lt;BR /&gt;restrict 127.0.0.1&lt;BR /&gt;restrict -6 ::1&lt;BR /&gt;driftfile /etc/ntp.drift&lt;BR /&gt;server xx.xx.xx.xx&lt;BR /&gt;server xx.xx.xx.xx&lt;BR /&gt;tos maxdist 15&lt;BR /&gt;tos maxdist 30&lt;BR /&gt;logconfig +clockstatus +peerstatus +sysstatus +syncstatus&lt;/P&gt;&lt;P&gt;and just FYI, the KB 86255 ending statement " Note: Please note that the "tos maxdist" config will not persist across reboot ." does not appear to be correct.&amp;nbsp; I have rebooted multiple times and these settings remain in my ntp.conf file after every reboot.&lt;/P&gt;</description>
      <pubDate>Tue, 12 Jul 2022 23:32:50 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/NTP-Why-will-my-host-NOT-sync-time-to-the-NTP-source/m-p/2918463#M282787</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-07-12T23:32:50Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2907529#M281408</link>
      <description>&lt;P&gt;My response from support included:&lt;/P&gt;&lt;P&gt;&lt;EM&gt;Engineering has confirmed that the fix will be part of next ESXi 7 u3 release, planned tentatively to be released in later part of June 2022.&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&lt;EM&gt;(Note: Release timeline is tentative and could vary depending on internal scenarios).&lt;/EM&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So it may be released in a future rev of 7.0 U3 or future 8.0 - but in either case it appears to be an acknowledged bug that will have a fix.&lt;/P&gt;</description>
      <pubDate>Thu, 05 May 2022 16:35:23 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2907529#M281408</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-05-05T16:35:23Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2905393#M281224</link>
      <description>&lt;P&gt;Latest update from GSS:&amp;nbsp; "engaged our engineering team who have acknowledged this issue and are actively working on a fix. Currently in an internal testing phase"&lt;/P&gt;</description>
      <pubDate>Fri, 22 Apr 2022 02:37:19 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2905393#M281224</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-04-22T02:37:19Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2904389#M281150</link>
      <description>&lt;P&gt;thanks&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/360674"&gt;@stanm88&lt;/a&gt;&amp;nbsp;. But I think that's just the standard set of commands to delete and recreate the productLocker symlink to your target location? I've been doing the autobackup.sh for some time as well.&amp;nbsp; &amp;nbsp;While your new productLocker symlink setting will be retained across multiple reboots so long as you do not use VUM/vLCM, I believe 100% this symlink is going to get reverted to&amp;nbsp;productLocker -&amp;gt; /SharedLocker when you next apply any update via VUM (and perform the subsequent reboot.) Does not matter whether it is a single driver update that is performed or a minor revision upgrade like 7.0 U3c to 7.0 U3d, the symlink gets reverted by invoking VUM to do the work.&amp;nbsp; The same driver update or ESXi update applied manually via CLI followed by manual reboot does NOT revert the symlink.&lt;/P&gt;</description>
      <pubDate>Thu, 14 Apr 2022 22:18:39 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2904389#M281150</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-04-14T22:18:39Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2904378#M281148</link>
      <description>&lt;P&gt;Today's update:&lt;/P&gt;&lt;P&gt;We are..."engaging the engineering team to provide a fix for this issue"&lt;/P&gt;</description>
      <pubDate>Thu, 14 Apr 2022 19:23:59 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2904378#M281148</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-04-14T19:23:59Z</dc:date>
    </item>
    <item>
      <title>Re: ESXi 7.0U3 and Software RAID</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/ESXi-7-0U3-and-Software-RAID/m-p/2904252#M281139</link>
      <description>&lt;P&gt;As&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/2443"&gt;@continuum&lt;/a&gt;&amp;nbsp;said - strike this thought from your consciousness &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@677206E94727C39F3BB2721E5A55F2C1/emoticons/1f609.png" alt=":winking_face:" title=":winking_face:" /&gt;&amp;nbsp; Software RAID of any kind is absolutely unsupported under ESXi.&amp;nbsp; I would check the compatibility list and buy a card with a compatible RAID chipset.&amp;nbsp; As an aside, use 7.0 U3c or U3d, nothing earlier than U3c.&lt;/P&gt;</description>
      <pubDate>Thu, 14 Apr 2022 05:26:19 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/ESXi-7-0U3-and-Software-RAID/m-p/2904252#M281139</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-04-14T05:26:19Z</dc:date>
    </item>
    <item>
      <title>Re: VMware Tools</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/VMware-Tools/m-p/2904251#M281138</link>
      <description>&lt;P&gt;It is correct the specific vmTools versions come bundled with ESXi, as others have indicated.&amp;nbsp; If you upgrade VMTools on a vm, it will get the Tools version that is bundled with your host version.&amp;nbsp; However, vmTools have been forward and backward compatible to host versions for many years.&amp;nbsp; If you are in a shared storage environment, you can upload vmTools source files to a shared location accessible to all hosts and point to that location so that no matter what host your vm is on, if your hosts are of various versions(i.e. you are in the middle of an upgrade cycle, etc.) the currency of its vmTools installation is always compared against what is in that one central location rather than what is provided locally on each host.&lt;/P&gt;&lt;P&gt;These are excellent guides to configuring productLocker to point to shared storage &lt;A href="https://kb.vmware.com/s/article/2129825" target="_blank"&gt;https://kb.vmware.com/s/article/2129825&lt;/A&gt;&amp;nbsp;and :&lt;A href="https://www.vladan.fr/configure-vmware-tools-update-from-shared-productlocker-location/" target="_blank"&gt;https://www.vladan.fr/configure-vmware-tools-update-from-shared-productlocker-location/&lt;/A&gt;&lt;/P&gt;&lt;P&gt;That being said, I believe there is a bug in 7.0 U3 that is causing this setting to be reset to default value on a host every time VUM is used to apply updates to that host.&amp;nbsp; Follow here for updates &amp;gt;&amp;nbsp;&lt;A href="https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2903857#M281104" target="_blank"&gt;https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2903857#M281104&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 14 Apr 2022 05:17:54 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/VMware-Tools/m-p/2904251#M281138</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-04-14T05:17:54Z</dc:date>
    </item>
    <item>
      <title>Re: SQL Server VM and SCSI controllers</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SQL-Server-VM-and-SCSI-controllers/m-p/2904250#M281137</link>
      <description>&lt;P&gt;There are myriad considerations to properly deploy and optimize a SQL vm; it really depends if you are tuning this vm for maximum performance or more for fairness and being a good neighbor in a shared environment.&amp;nbsp; I like your disk distribution across controllers as you have it written, but would consider moving the SQL binaries to the OS disk.in order to isolate SQL data to a unique controller. General recommendations:&amp;nbsp; Use only PVSCSI controllers and format the OS/application partition with standard 4k clusters and any SQL data/log/tempDB partition with 64k cluster size and UseLargeFRS option.&amp;nbsp; Always install the latest vmTools on the vm.&amp;nbsp; Try to keep the vm within a single NUMA node boundary for physical cores (this depends on your host processor mfr/generation) and also limit vRAM to memory owned by that single NUMA node.&amp;nbsp; You didn't give any details of your desired SQL vm specs, ESXi version, nor the underlying host hardware or back-end storage type (traditional datastore or vVols?) and connectivity, so it's tough to give general advice beyond this.&amp;nbsp;&amp;nbsp;If your vm needs to be larger than the resources available in a single NUMA node, you are talking about a wide vm which requires care to properly configure. If you need the resources of &amp;gt;2 NUMA nodes then you are talking about Monster vm's which require significant design and configuration effort to properly tune.&amp;nbsp;&lt;/P&gt;&lt;P&gt;In a basic shared environment with limited host resources serving many vm's I would resist the urge to do too much additional vm tuning beyond the few things listed above - vSphere default settings are generally designed for fairness and you run the risk of becoming a noisy neighbor by changing defaults if you are unsure of the impact on the rest of your environment.&lt;/P&gt;&lt;P&gt;If you are tuning for maximum performance and can isolate your SQL vm on a host or cluster environment with no CPU over-commitment that would be ideal - then you can start to also look at things like specifying cores/socket to match the underlying CPU architecture, modifying PVSCSI driver queue depths in the guest OS, modifying queue depths on your host hba's, etc. to further increase I/O performance, but all of these require a deep understanding of the physical environment backing this vm.&amp;nbsp; The &lt;A href="https://blogs.vmware.com/performance/2021/09/extreme-performance-series-monster-database-virtual-machines.html" target="_self"&gt;VMware Extreme Performance series&lt;/A&gt; gives a ton of great information in this regard, as does the&amp;nbsp;&lt;A href="http://%20https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf" target="_self"&gt;ARCHITECTING MICROSOFT SQL SERVER ON VMWARE VSPHERE Best Practices Guide&lt;/A&gt;.&amp;nbsp; Also check out old VMWorld presentation videos on the topic:&amp;nbsp;&amp;nbsp;&lt;A href="https://youtu.be/5EJu2ER-aLI" target="_blank"&gt;https://youtu.be/5EJu2ER-aLI&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 14 Apr 2022 05:00:44 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SQL-Server-VM-and-SCSI-controllers/m-p/2904250#M281137</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-04-14T05:00:44Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2903857#M281104</link>
      <description>&lt;P&gt;Quick case update - GSS advised me to ensure that&amp;nbsp;&lt;SPAN&gt;UserVars.ToolsRamdisk value was set to 1 and reboot&amp;nbsp; prior to application of VUM updates, however I proved that setting does NOT eliminate the productLocker location getting reset from &amp;nbsp;productLocker -&amp;gt; /vmfs/volumes/&amp;lt;volume_name&amp;gt;/SharedLocker to new value productLocker -&amp;gt; /SharedLocker on the reboot following any VUM application of updates.&amp;nbsp; Tried it with UserVars.ToolsRamdisk set to both 0 and 1, it does not make a difference in the result.&amp;nbsp; Uploaded more logs, still in progress.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 12 Apr 2022 12:19:05 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2903857#M281104</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-04-12T12:19:05Z</dc:date>
    </item>
    <item>
      <title>Re: productLocker location getting changed when applying any patches via VUM?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2901562#M280950</link>
      <description>&lt;P&gt;I have opened a case for this as well.&amp;nbsp; Will post updates here when I have one.&amp;nbsp; I continue to see this issue when applying 7.0 U3d build&amp;nbsp;&lt;SPAN&gt;19482537&lt;/SPAN&gt; via VUM/vLCM to hosts that were previously on version 7.0 U3c&lt;/P&gt;</description>
      <pubDate>Thu, 31 Mar 2022 14:09:35 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/productLocker-location-getting-changed-when-applying-any-patches/m-p/2901562#M280950</guid>
      <dc:creator>PatrickDLong</dc:creator>
      <dc:date>2022-03-31T14:09:35Z</dc:date>
    </item>
  </channel>
</rss>

