<?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>pkvmw Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>pkvmw Tracker</description>
    <pubDate>Sat, 25 Nov 2023 07:05:10 GMT</pubDate>
    <dc:date>2023-11-25T07:05:10Z</dc:date>
    <item>
      <title>Re: How can I find out who created this VMware snapshot on ESXi through PuTTY? Please help.</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/How-can-I-find-out-who-created-this-VMware-snapshot-on-ESXi/m-p/2986008#M290002</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;you can do a log review of /var/run/log/hostd.log on the ESXi host and check if the logs do still cover the snapshot event. Usually it should note the executing user in the log message.&lt;/P&gt;&lt;P&gt;You can check the vmware.log of the VM directory possibly to find out a timeframe when a snapshot was performed.&lt;/P&gt;&lt;P&gt;Depending on how much is occurring on the host and how long ago this snapshot was created, the logs might already have rolled over. You can fallback to your syslog server, if configured, and get older logs from there.&lt;/P&gt;&lt;P&gt;Hope this helps.&lt;/P&gt;</description>
      <pubDate>Sun, 10 Sep 2023 12:21:40 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/How-can-I-find-out-who-created-this-VMware-snapshot-on-ESXi/m-p/2986008#M290002</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2023-09-10T12:21:40Z</dc:date>
    </item>
    <item>
      <title>Re: Simulate Hard Drive failure on ESXi VM</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Simulate-Hard-Drive-failure-on-ESXi-VM/m-p/2986007#M290001</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;can you please be more specific where you would like to simulate a disk failure? I doubt you can fake a disk failure on a virtual disk of a VM, as it's a virtual disk. The VM, or more precisely the Guest OS, should not care about any underlying disk failures.&lt;/P&gt;&lt;P&gt;If you're speaking about faking disk failures on ESXi, you can do that by using some internal commands to do so. But noteworthy, best not to run this on crucial production hosts obviously.&lt;/P&gt;&lt;P&gt;To inject PDL (Permanent Device Loss):&lt;/P&gt;&lt;P&gt;vsish -e set /reliability/vmkstress/ScsiPathInjectError 1&lt;BR /&gt;vsish -e set /storage/scsifw/paths/&amp;lt;path of the device/PE &amp;gt;/injectError 0x013E0400000002 update&lt;/P&gt;&lt;P&gt;To clear the PDL state:&lt;/P&gt;&lt;P&gt;vsish -e set /storage/scsifw/paths/&amp;lt;path of the device/PE &amp;gt;/injectError 0x000000&lt;BR /&gt;vsish -e set /reliability/vmkstress/ScsiPathInjectError 0&lt;/P&gt;&lt;P&gt;To check available disk paths:&lt;/P&gt;&lt;P&gt;vsish -e ls /storage/scsifw/paths/&lt;/P&gt;&lt;P&gt;Does this answer your question?&lt;/P&gt;</description>
      <pubDate>Sun, 10 Sep 2023 12:19:40 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Simulate-Hard-Drive-failure-on-ESXi-VM/m-p/2986007#M290001</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2023-09-10T12:19:40Z</dc:date>
    </item>
    <item>
      <title>Re: vSAN backup restore.</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-backup-restore/m-p/2963538#M15097</link>
      <description>&lt;P&gt;Just my 2 cents here:&lt;/P&gt;&lt;P&gt;You could backup the vSAN configuration before the host fails (e.g. after every configuration change manually, or periodically automated via PowerShell script or whatsoever). When one of your hosts fail, you need to install the same build version the configuration backup was taken on and then you can restore the backup.&lt;/P&gt;&lt;P&gt;See here:&amp;nbsp;&lt;A href="https://kb.vmware.com/s/article/2042141" target="_blank"&gt;https://kb.vmware.com/s/article/2042141&lt;/A&gt;. So backing up all hosts is as easy as:&lt;BR /&gt;$ Get-VMHost | Get-VMHostFirmware -BackupConfiguration -DestinationPath C:\Downloads\&lt;BR /&gt;(or Get-Cluster -Name "MainCluster" | Get-VMHost | Get-VMHostFirmware [...] - if I recall correct)&lt;/P&gt;&lt;P&gt;Also noteworthy, when it comes to vSAN is that it does recognize the vSAN disks automatically after re-installing the host. The data on the vSAN diskgroups is not lost, as long as the disks stay healthy. So you "only" need to re-do your basic ESXi configuration like networking settings.&lt;/P&gt;</description>
      <pubDate>Wed, 12 Apr 2023 13:58:40 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-backup-restore/m-p/2963538#M15097</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2023-04-12T13:58:40Z</dc:date>
    </item>
    <item>
      <title>Re: Restoring ESXi from the 6.7 version config bundle backup after upgrading to 7.0 u3 fails with th</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Restoring-ESXi-from-the-6-7-version-config-bundle-backup-after/m-p/2963530#M287624</link>
      <description>&lt;P&gt;I'm not sure which documents - regarding what topic exactly? If I recall you can open the config file you've pulled before to check on which build it was taken on. The build number should be in some readable text-based file.&lt;/P&gt;</description>
      <pubDate>Wed, 12 Apr 2023 13:38:42 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Restoring-ESXi-from-the-6-7-version-config-bundle-backup-after/m-p/2963530#M287624</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2023-04-12T13:38:42Z</dc:date>
    </item>
    <item>
      <title>Re: Cannot complete login due to an incorrect user name or password.</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Cannot-complete-login-due-to-an-incorrect-user-name-or-password/m-p/2963527#M287623</link>
      <description>&lt;P&gt;Adding to what&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5541222"&gt;@jsm79&lt;/a&gt;&amp;nbsp;said: ESXi does temporarily block your access for the given account if you're failing to authenticate too often. I believe after 3 or 5 attempts it will block the account for 15 minutes or so.&lt;/P&gt;&lt;P&gt;I've seen it more than once that there're monitoring systems or other automated solutions doing automated logins via API/SSH with wrong passwords, essentially repeatedly causing the account to be blocked.&lt;/P&gt;&lt;P&gt;If that's not the case here, I'd say the credentials are indeed wrong and you might need to either use vCenter to reset the password or to re-install ESXi to set up a new password.&lt;/P&gt;</description>
      <pubDate>Wed, 12 Apr 2023 13:35:55 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Cannot-complete-login-due-to-an-incorrect-user-name-or-password/m-p/2963527#M287623</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2023-04-12T13:35:55Z</dc:date>
    </item>
    <item>
      <title>Re: Restoring ESXi from the 6.7 version config bundle backup after upgrading to 7.0 u3 fails with th</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Restoring-ESXi-from-the-6-7-version-config-bundle-backup-after/m-p/2963109#M287565</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5617541"&gt;@shammurthy&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;you can only restore the config backup on the same ESXi build version it was taken on. So you can't restore a config taken on ESXi 6.7 on e.g. 7.0 U3. It needs to be the exact same build version.&lt;/P&gt;</description>
      <pubDate>Sun, 09 Apr 2023 11:42:51 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Restoring-ESXi-from-the-6-7-version-config-bundle-backup-after/m-p/2963109#M287565</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2023-04-09T11:42:51Z</dc:date>
    </item>
    <item>
      <title>Re: ESIX 8.0 No Network Adapters No network adapters were detected</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/ESIX-8-0-No-Network-Adapters-No-network-adapters-were-detected/m-p/2963108#M287564</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5607471"&gt;@mmbabjiml&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;Realtek is not developing drivers for the ESXi platform, so those cards cannot be used with ESXi unfortunately.&lt;/P&gt;&lt;P&gt;There were 3rd-party-crafted Linux drivers for ESXi back in the vSphere 6.x days, but the legacy vmklinux (allowing to use Linux drivers on ESXi) was deprecated longer time ago and removed in vSphere 7.0.&lt;/P&gt;&lt;P&gt;You might be better of getting some (used) Intel NIC, which do usually work with ESXi. You can check the HCL for any working models and maybe get hands on a cheap, working NIC.&lt;/P&gt;&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/1285119"&gt;@supergsm&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;not sure on which facts this is based on. The fact is, that hardware vendors are responsible for developing drivers and firmware for their own hardware and also respectively for platforms they decide to support. As of today, Realtek is not developing drivers for ESXi nor does certify them with us.&lt;/P&gt;&lt;P&gt;If you want Realtek drivers, please reach out to the hardware vendor Realtek.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sun, 09 Apr 2023 11:24:19 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/ESIX-8-0-No-Network-Adapters-No-network-adapters-were-detected/m-p/2963108#M287564</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2023-04-09T11:24:19Z</dc:date>
    </item>
    <item>
      <title>Re: Move iSCSI Target Service</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Move-iSCSI-Target-Service/m-p/2963106#M15077</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/1773180"&gt;@nitro_jawt&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;I'm not sure if I fully understand your query. The active path for iSCSI to the I/O Owner of the iSCSI LUN will move across hosts automatically if needed - e.g. when entering maintenance mode for the host or during a failure. The owner is automatically decided by vSAN and cannot be manually influenced.&lt;/P&gt;&lt;P&gt;From a data perspective the iSCSI LUN is a vSAN object, which is split across the entire vSAN cluster as any other objects. You can't move the data of the object to a specific host, as there's also no need to.&lt;/P&gt;&lt;P&gt;-pk&lt;/P&gt;</description>
      <pubDate>Sun, 09 Apr 2023 10:55:41 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Move-iSCSI-Target-Service/m-p/2963106#M15077</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2023-04-09T10:55:41Z</dc:date>
    </item>
    <item>
      <title>Re: vSAN "none - Stretched Cluster" Ploicy</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-quot-none-Stretched-Cluster-quot-Ploicy/m-p/2963099#M15076</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/3028138"&gt;@Vaskomozz&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;as&amp;nbsp;Duncan and the KB states, the "None - standard cluster" should not be used for Stretched Clusters, even for non-critical VMs. As the KB explains, this leads to vSAN making the wrong placement decisions and potentially ending up in impactful for your entire environment - also affecting your critical VMs.&lt;/P&gt;&lt;P&gt;If you don't need FTT=1 across your sites, you can use "None - stretched cluster" or one of the "None - keep data on [...]" storage policies to pin the data on one specific site.&lt;/P&gt;&lt;P&gt;Regarding the Witness: The witness only holds metadata components and no actual VM data of your VMs.&lt;/P&gt;&lt;P&gt;- pk&lt;/P&gt;</description>
      <pubDate>Sun, 09 Apr 2023 08:32:10 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-quot-none-Stretched-Cluster-quot-Ploicy/m-p/2963099#M15076</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2023-04-09T08:32:10Z</dc:date>
    </item>
    <item>
      <title>Re: ESXi 7.0 - glibc version</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/ESXi-7-0-glibc-version/m-p/2913877#M282185</link>
      <description>&lt;P&gt;I guess you should be fine with 7.0 U3 then?&lt;/P&gt;&lt;P&gt;[root@ieesxi01:~] vmware -vl&lt;BR /&gt;VMware ESXi 7.0.3 build-19193900&lt;BR /&gt;VMware ESXi 7.0 Update 3&lt;/P&gt;&lt;P&gt;[root@ieesxi01:~] ls -lsh /lib64/glib*&lt;BR /&gt;ls: /lib64/glib*: No such file or directory&lt;/P&gt;</description>
      <pubDate>Mon, 13 Jun 2022 14:23:18 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/ESXi-7-0-glibc-version/m-p/2913877#M282185</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-06-13T14:23:18Z</dc:date>
    </item>
    <item>
      <title>Re: Which TLS versions ESX6.0.0 support?</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Which-TLS-versions-ESX6-0-0-support/m-p/2912876#M282083</link>
      <description>&lt;P&gt;Support for ESXi 6.0 completely ended on 12th of March 2022 (see &lt;A href="https://lifecycle.vmware.com/" target="_blank"&gt;https://lifecycle.vmware.com&lt;/A&gt;). So should security be a priority or concern, you would be better of with upgrading to a newer, supported ESXi release as the TLS version won't help much here.&lt;/P&gt;&lt;P&gt;If you want to check which TLS versions are offered from several components, you could try following:&lt;/P&gt;&lt;P&gt;&lt;A href="https://stackoverflow.com/questions/40557031/command-prompt-to-check-tls-version-required-by-a-host" target="_blank"&gt;https://stackoverflow.com/questions/40557031/command-prompt-to-check-tls-version-required-by-a-host&lt;/A&gt;&lt;BR /&gt;&lt;A href="https://github.com/drwetter/testssl.sh" target="_blank"&gt;https://github.com/drwetter/testssl.sh&lt;/A&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 06 Jun 2022 15:36:39 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Which-TLS-versions-ESX6-0-0-support/m-p/2912876#M282083</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-06-06T15:36:39Z</dc:date>
    </item>
    <item>
      <title>Re: VM Failed - The attempted operation cannot be performed in the current state (Powered off)</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/VM-Failed-The-attempted-operation-cannot-be-performed-in-the/m-p/2912278#M282020</link>
      <description>&lt;P&gt;Does give the log file at /var/run/log/hostd.log on the ESXi host itself give any clue? Just "tail -f" the file during power-on or search the timestamp. There should be something more detailed why the PowerOn failed.&lt;/P&gt;</description>
      <pubDate>Thu, 02 Jun 2022 08:11:10 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/VM-Failed-The-attempted-operation-cannot-be-performed-in-the/m-p/2912278#M282020</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-06-02T08:11:10Z</dc:date>
    </item>
    <item>
      <title>Re: Nested Fault Domains for 2-node STRECHED clusters</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Nested-Fault-Domains-for-2-node-STRECHED-clusters/m-p/2912277#M14311</link>
      <description>&lt;P&gt;Nested Fault Domains are available for 2-node clusters, yes. But it requires at least 3 disk groups per host to have in-host RAID1:&lt;BR /&gt;&lt;A href="https://core.vmware.com/blog/nested-fault-domain-2-node-cluster-deployments" target="_blank"&gt;https://core.vmware.com/blog/nested-fault-domain-2-node-cluster-deployments&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Also interesting read:&amp;nbsp;&lt;A href="https://www.yellow-bricks.com/2022/03/17/stretched-cluster-witness-failure-resilience-in-vsan-7-0/" target="_blank"&gt;https://www.yellow-bricks.com/2022/03/17/stretched-cluster-witness-failure-resilience-in-vsan-7-0/&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Thu, 02 Jun 2022 08:04:53 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/Nested-Fault-Domains-for-2-node-STRECHED-clusters/m-p/2912277#M14311</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-06-02T08:04:53Z</dc:date>
    </item>
    <item>
      <title>Re: repeated hbr-agent logs</title>
      <link>https://communities.vmware.com/t5/vSphere-Replication-Discussions/repeated-hbr-agent-logs/m-p/2912130#M3596</link>
      <description>&lt;P&gt;If I recall correctly, this as 'normal'. But you could try using logfilters to limit the amount of logs if you want to:&amp;nbsp;&lt;A href="https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.install.doc/GUID-D0D77526-65DC-4D08-A52F-51D5B0DAF8C3.html" target="_blank"&gt;https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.install.doc/GUID-D0D77526-65DC-4D08-A52F-51D5B0DAF8C3.html&lt;/A&gt;&amp;nbsp;(Never tested myself)&lt;/P&gt;</description>
      <pubDate>Wed, 01 Jun 2022 12:08:00 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Replication-Discussions/repeated-hbr-agent-logs/m-p/2912130#M3596</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-06-01T12:08:00Z</dc:date>
    </item>
    <item>
      <title>Re: vSAN component size and distribution</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-component-size-and-distribution/m-p/2911913#M14297</link>
      <description>&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/24614"&gt;@depping&lt;/a&gt;&amp;nbsp;Based on an internal training for vSAN 7.0 U1 we do indeed re-create all components split by the new total size after the disk increasement. I can share the link internally, if you're curious.&lt;/P&gt;&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5555219"&gt;@tim-may&lt;/a&gt;&amp;nbsp;Might be a weird question, but did your customer recently open a vSAN-related SR for this topic?&lt;/P&gt;</description>
      <pubDate>Tue, 31 May 2022 10:12:03 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-component-size-and-distribution/m-p/2911913#M14297</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-05-31T10:12:03Z</dc:date>
    </item>
    <item>
      <title>Re: disaster esxi Build Number</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/disaster-esxi-Build-Number/m-p/2911751#M281963</link>
      <description>&lt;P&gt;I think the question should rather be - as Veeam is doing the replication in your case - if Veeam supports/tested this scenario. Also, you could perform a test failover and see if it works in a practical way.&lt;/P&gt;&lt;P&gt;But as Andre said, it was only a small bugfix and I should work. But I think a practical failover test won't hurt anyway.&lt;/P&gt;</description>
      <pubDate>Mon, 30 May 2022 10:22:53 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/disaster-esxi-Build-Number/m-p/2911751#M281963</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-05-30T10:22:53Z</dc:date>
    </item>
    <item>
      <title>Re: HA warning</title>
      <link>https://communities.vmware.com/t5/Availability-HA-FT-Discussions/HA-warning/m-p/2911446#M7340</link>
      <description>&lt;P&gt;You can disable and re-enable vSphere HA to get rid of this alert.&lt;/P&gt;</description>
      <pubDate>Fri, 27 May 2022 09:52:47 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/Availability-HA-FT-Discussions/HA-warning/m-p/2911446#M7340</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-05-27T09:52:47Z</dc:date>
    </item>
    <item>
      <title>Re: Purple screen of death intermittently appears</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Purple-screen-of-death-intermittently-appears/m-p/2911052#M281904</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5558805"&gt;@Staurus&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;according to internal research it is most likely something wrong with USB - so the USB controller or USB stick/sdcard. Alternatively could be faulty CPU or memory.&lt;/P&gt;&lt;P&gt;Your hardware vendor should further investigate here. If you need an official statement/verification or more precise details, I'd suggest raising a SR. (Because it's not possible without Engineering checking the crashdump)&lt;/P&gt;&lt;P&gt;Regards,&lt;BR /&gt;Patrik&lt;/P&gt;</description>
      <pubDate>Wed, 25 May 2022 07:53:26 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Purple-screen-of-death-intermittently-appears/m-p/2911052#M281904</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-05-25T07:53:26Z</dc:date>
    </item>
    <item>
      <title>Re: Pink screen error</title>
      <link>https://communities.vmware.com/t5/ESXi-Arm-Fling-Discussions/Pink-screen-error/m-p/2910183#M253</link>
      <description>&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/274885"&gt;@scott28tt&lt;/a&gt;&amp;nbsp;This isn't on ARM hardware for sure, as there's no ESXi 6.7.&lt;/P&gt;&lt;P&gt;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5558107"&gt;@yk24slb&lt;/a&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;To answer your question: PSODs can be both, hardware and software-related. Sometimes it's possible to guess the reason just from reading through the stacktrace and which components are involved, otherwise usually further internal analysis are required - which requires you to file a SR.&lt;/P&gt;&lt;P&gt;So as you can see in the screenshots the PSOD is caused by a malfunctioning driver, aacraid to be specific. When reading from bottom to top, you can see the code functions it travels through which lead to the PSOD being triggered. That's the driver for your storage controller/hardware RAID controller.&lt;/P&gt;&lt;P&gt;I'd suggest to check the HCL and ensure you have the correct driver and firmware combination installed - see&amp;nbsp;&lt;A href="https://www.vmware.com/resources/compatibility/search.php?deviceCategory=io" target="_blank"&gt;https://www.vmware.com/resources/compatibility/search.php?deviceCategory=io&lt;/A&gt;. Such PSOD can also occur due to mismatching driver and firmware combination.&lt;/P&gt;&lt;P&gt;In any case it would probably make sense to re-install the driver nonetheless. According to the message ESXi can't verify the signature of the "scsi-aacraid" driver. So either there's no signature (which sometimes isn't), or maybe the driver VIB is simply corrupt.&lt;/P&gt;&lt;P&gt;If assistance from VMware is required, ensure you have a full core dump available and raise a SR for this for further analysis. But usually you might get redirect to your hardware vendor after, as driver/firmware are developed and supported from them.&lt;/P&gt;&lt;P&gt;Regards,&lt;BR /&gt;Patrik&lt;/P&gt;</description>
      <pubDate>Fri, 20 May 2022 09:25:40 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Arm-Fling-Discussions/Pink-screen-error/m-p/2910183#M253</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-05-20T09:25:40Z</dc:date>
    </item>
    <item>
      <title>Re: solution user certificate in vc 7.0</title>
      <link>https://communities.vmware.com/t5/vSphere-Upgrade-Install/solution-user-certificate-in-vc-7-0/m-p/2909687#M34001</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://communities.vmware.com/t5/user/viewprofilepage/user-id/5530437"&gt;@Debashis5352&lt;/a&gt;,&lt;/P&gt;&lt;P&gt;not sure how it works using the Certificate Management, but you can also check the certificates via CLI using following one-liner in the vCenter-bash-shell:&lt;/P&gt;&lt;P&gt;$&amp;nbsp;for i in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo STORE $i; sudo /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $i --text | egrep "Alias|Not After"; done&lt;/P&gt;&lt;P&gt;&lt;FONT size="1 2 3 4 5 6 7"&gt;(Source of the command:&amp;nbsp;&lt;A href="https://kb.vmware.com/s/article/76719" target="_blank"&gt;https://kb.vmware.com/s/article/76719&lt;/A&gt;)&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;If one or more are expired, you can renew them using the certificate-manager (option 6 if I'm not mistaken).&lt;/P&gt;&lt;P&gt;Regards,&lt;BR /&gt;Patrik&lt;/P&gt;</description>
      <pubDate>Wed, 18 May 2022 11:38:40 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/vSphere-Upgrade-Install/solution-user-certificate-in-vc-7-0/m-p/2909687#M34001</guid>
      <dc:creator>pkvmw</dc:creator>
      <dc:date>2022-05-18T11:38:40Z</dc:date>
    </item>
  </channel>
</rss>

