<?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>vbabic Tracker</title>
    <link>https://communities.vmware.com/wbsdv95928/tracker</link>
    <description>vbabic Tracker</description>
    <pubDate>Sat, 25 Nov 2023 07:03:03 GMT</pubDate>
    <dc:date>2023-11-25T07:03:03Z</dc:date>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2870698#M278363</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;I'm sorry, but there's a big difference between a new major release not supporting a server/CPU generation that is literally 10 years old and not sold for 7-8 years and suddenly (in an update) deprecating something that was until "yesterday" fully supported and is still being sold today! Even today, go look at the VMware's own HCL (!), vsan ready nodes for example and you will find nodes with SD cards fully supported even for version 7.0 Update 3! That means people are still buying them if they are not reading every blog and KB.&lt;/P&gt;&lt;P&gt;And like us with a 1 year old server (so expected to be in productions for at least 4 more years), "tomorrow" they will not be able to upgrade to the next version. And not because they didn't check the HCL and bought 10 year old hardware, but because of a software fiasco.. It's normal to do a fresh install when you retire a 5 year old server, It's not normal to be forced to do a HW upgrade and reinstall a 2 year old server...&lt;/P&gt;&lt;P&gt;If you think that is just the way it always was and should be, I respectfully disagree...maybe it's expected for free software, it was never normal for VMware..&lt;/P&gt;</description>
      <pubDate>Thu, 07 Oct 2021 09:18:06 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2870698#M278363</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-10-07T09:18:06Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2870530#M278342</link>
      <description>&lt;P&gt;Yes, that was clear as soon as these issues started. But what to do with all the current servers... Since somehow I doubt the ones who caused this mess (VMware) will cover the costs of retrofitting servers with new boot devices, is a (not shared) SAN LUN an option for the ESX-OSData partition?&lt;/P&gt;&lt;P&gt;The new blog post and the KB articles mention only locally attached devices, but the "summary" table in the blog post also has "Managed FCoE/iSCSI LUN" as an option, so which is true?&lt;/P&gt;&lt;P&gt;&lt;A href="https://blogs.vmware.com/vsphere/2021/09/esxi-7-boot-media-consideration-vmware-technical-guidance.html" target="_blank"&gt;https://blogs.vmware.com/vsphere/2021/09/esxi-7-boot-media-consideration-vmware-technical-guidance.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Another useful thing to have would be a supported way of replacing a boot disk (without reinstall), since it's not only a question of buying new devices, but (AFAIK) there's no supported way of replacing a boot disk and a reinstall of all servers would probably be even more expensive (in man hours) than the hardware itself..&lt;/P&gt;</description>
      <pubDate>Wed, 06 Oct 2021 16:44:46 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2870530#M278342</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-10-06T16:44:46Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865183#M277854</link>
      <description>&lt;P&gt;I'm sorry, but that story sounds like a face saving exercise for VMware, because&lt;/P&gt;&lt;P&gt;1. Vendors obviously haven't heard that because they continued to sell and recommend SD Cards, on VMware's own HCL! Event if they&amp;nbsp; ignored warnings from VMware, wouldn't they (VMware) say something about it publicly then so we, the customers, know about it?&lt;/P&gt;&lt;P&gt;2. VMware itself obviously hasn't heard that, because 2 years later, in 2020, when they released 7.0, they explicitly documented that SD Cards are fully supported in 7.0 the same way as in 6.7. The only change was raising the minimum size to 32 GB, and that only for new installs.&lt;/P&gt;&lt;P&gt;So the next opportunity to do what you say they should have done is the next major release, and even then it should be deprecated, not immediately unsupported (except maybe for new installs)&lt;/P&gt;</description>
      <pubDate>Fri, 03 Sep 2021 13:18:19 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865183#M277854</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-09-03T13:18:19Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865156#M277847</link>
      <description>&lt;P&gt;Thanks for the info Duncan, we eagerly wait for the new article..&lt;/P&gt;&lt;P&gt;Not that the "main" article about the issue is completely clear, saying that 6.7 is affected by the VMFS-L (!) corruption on SD cards...which also causes Skyline alerts on 6.7 hosts..&lt;/P&gt;&lt;P&gt;&lt;A href="https://kb.vmware.com/s/article/83376" target="_blank"&gt;https://kb.vmware.com/s/article/83376&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 03 Sep 2021 10:28:09 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865156#M277847</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-09-03T10:28:09Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865117#M277839</link>
      <description>&lt;P&gt;I'm not surprised... Fortunately, screenshot was made &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; Just in case someone calls us crazy for thinking VMware would ever do something like that..&lt;/P&gt;&lt;P&gt;Let's just hope they learned something and the new version of the article will be more "customer friendly"&lt;/P&gt;</description>
      <pubDate>Fri, 03 Sep 2021 08:21:35 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865117#M277839</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-09-03T08:21:35Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865053#M277832</link>
      <description>&lt;P&gt;Again, this is not about the scratch partition, that was always the case. Where do you see ".locker, coredump, logs" in the article?&lt;/P&gt;&lt;P&gt;"Please move &lt;STRONG&gt;installation&lt;/STRONG&gt; to persistent storage"&lt;/P&gt;&lt;P&gt;"ESXi requires local persistent storage for &lt;STRONG&gt;operating system use, to store system state, configuration&lt;/STRONG&gt;, logs, and live data"&lt;/P&gt;&lt;P&gt;"&lt;SPAN&gt;A system with only a SD-Card/USB boot device is operating in an &lt;STRONG&gt;unsupported&lt;/STRONG&gt; state with the potential for &lt;STRONG&gt;premature corruption&lt;/STRONG&gt;"&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;You really don't see anything new here? Even if all that was best practice, the sudden change to "unsupported" is the main issue.&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;I am sure you followed all of those best practices you mention but I know from your website that you had a lot of PSODs because of this, why if this is nothing new? There are things on the boot disk that can't be redirected (so it couldn't have been a best practice) that previously could be on the SD Cards, but now they can't.&lt;/P&gt;&lt;P&gt;If they said when they released 7.0, SD Cards are deprecated and won't be supported in the next major release, that would be fine. No, they specifically stated they are still supported and what are the minimum sizes for upgrades and for new installs. Otherwise, I would have a lot less SD Cards in my servers by now...&lt;/P&gt;</description>
      <pubDate>Thu, 02 Sep 2021 21:41:41 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865053#M277832</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-09-02T21:41:41Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865007#M277816</link>
      <description>&lt;P&gt;Yes, the recommendation changed abruptly without prior notice. When things like this are done, responsible thing to do is do announce for example, this is the last major version to support this configuration, the next one will not. And VMware usually does this, but this was obviously not planned, but the consequence of a major screw up in planning and/or development.&lt;/P&gt;&lt;P&gt;When are you available to come and rebuild all our hosts free of charge? Of course, bring a bunch of boot devices with you... &lt;img class="lia-deferred-image lia-image-emoji" src="https://communities.vmware.com/html/@ED2F300321B6439B8A995ED3556300D9/emoticons/1f604.png" alt=":grinning_face_with_smiling_eyes:" title=":grinning_face_with_smiling_eyes:" /&gt;&lt;/P&gt;&lt;P&gt;Really, rebuild all hosts instead of an upgrade? Is this a Microsoft forum? That used to be the benefit of using VMware, same host going through 4-5 major releases without problems during their lifetime (that was when releases were every year)&lt;/P&gt;</description>
      <pubDate>Thu, 02 Sep 2021 16:14:55 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865007#M277816</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-09-02T16:14:55Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865005#M277815</link>
      <description>&lt;P&gt;Even for vSAN, another local device is not a requirement, trace logs can be redirected to a remote storage or (partly) to a syslog server or limited in size.&lt;/P&gt;&lt;P&gt;Anyway, even the vSAN Ready Nodes (still on the HCL) have the option to boot from SD card (with no additional local disks other than vSAN disks). Imagine you buy a bunch of them today, trusting they are a sure thing to be checked and tested, and by the time they arrive, they are unsupported.&lt;/P&gt;&lt;P&gt;At least now I know what I'll say to the VMware sales team trying to sell Tanzu to me...sorry, unsupported...&lt;/P&gt;</description>
      <pubDate>Thu, 02 Sep 2021 16:06:16 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2865005#M277815</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-09-02T16:06:16Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864986#M277809</link>
      <description>&lt;P&gt;Exactly, it's not about the scratch. This is the biggest screw up I have seen from VMware... and the sad part is they don't care and they try to minimize it and blame OEMs and customers for using supposedly low endurance cards (now it's obvious no card has a high enough endurance for their briliant design)&lt;/P&gt;&lt;P&gt;As I said, I haven't yet started upgrading to 7.0 because I don't consider it a stable version (I don't think anyone can argue about that in this thread)...what am I supposed to do now? Stay on 6.7 until my servers are old enough for replacement in 3-4 years?&lt;/P&gt;</description>
      <pubDate>Thu, 02 Sep 2021 14:42:59 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864986#M277809</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-09-02T14:42:59Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864977#M277805</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;If it is as you say, just about the scratch partition, like it always was, why the new article and new warnings - "Please move installation to persistent storage". *installation*, not /scratch&lt;/P&gt;&lt;P&gt;They clearly say that the only supported configuration is having a local persistent storage device that is not a SD-Card/USB boot device.&lt;/P&gt;&lt;P&gt;That is new. Maybe some people design their servers with extra disks lying around in the servers not being used, we don't. If I have local disks, they are for vSAN.&lt;/P&gt;&lt;P&gt;If I was buying local disks just for the /scratch partition, why would I even have the SD Card, I would use those disks for booting...&lt;/P&gt;&lt;P&gt;/scratch partition is of course redirected to a remote datastore, but this is about all other parts of the shiny new much improved&amp;nbsp;ESX-OSData partition which they found out doesn't support SD Cards, even though it did until 7.0 U2&lt;/P&gt;</description>
      <pubDate>Thu, 02 Sep 2021 14:18:19 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864977#M277805</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-09-02T14:18:19Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864969#M277803</link>
      <description>&lt;P&gt;Well this is great... Now there's a new article saying that having only SD card (or USB) is unsupported.&lt;/P&gt;&lt;P&gt;Now I am doubting even more that they actually fixed the issue (maybe just lessened the impact), obviously they changed the design too much without thinking or testing the currently supported hardware and it would be too much trouble for them to fix it now. So...dear customers, suddenly you're unsupported, tough luck! Oh wait, there's a simple workaround, just reinstall all your servers on new hardware...I am sure VMware will cover the cost...&lt;/P&gt;&lt;P&gt;&lt;A href="https://kb.vmware.com/s/article/85615?lang=en_US" target="_blank"&gt;https://kb.vmware.com/s/article/85615?lang=en_US&lt;/A&gt;&lt;/P&gt;&lt;P&gt;Great job!&lt;/P&gt;</description>
      <pubDate>Thu, 02 Sep 2021 13:38:16 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864969#M277803</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-09-02T13:38:16Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864422#M277735</link>
      <description>&lt;P&gt;&lt;SPAN&gt;&lt;FONT color="#565656"&gt;I&lt;/FONT&gt;&lt;/SPAN&gt;&lt;SPAN&gt;t doesn't know. It just sees an SD card and points you to the article, it does nothing.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 30 Aug 2021 15:48:39 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864422#M277735</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-08-30T15:48:39Z</dc:date>
    </item>
    <item>
      <title>Re: SD Boot issue Solution in 7.x</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864387#M277728</link>
      <description>&lt;P&gt;It just points you to the KB article.&lt;/P&gt;&lt;P&gt;As it did for us even though we only have 6.7 hosts. I guess because the article states that 6.7 is also affected (with no resolution) even though it also states:&lt;/P&gt;&lt;P&gt;"Potential VMFS-L Locker partition corruption on SD cards in &lt;STRONG&gt;ESXi 7.0&lt;/STRONG&gt;"&lt;/P&gt;&lt;P&gt;"&lt;STRONG&gt;Starting in ESXi 7.0&lt;/STRONG&gt;, the boot partition is formatted as VMFS-L instead of FAT"&lt;/P&gt;&lt;P&gt;Does anyone read these articles before they publish them?&lt;/P&gt;&lt;P&gt;Unfortunately, it seems that long gone are the days when we only had to wait for U1 to consider the new ESXi version stable, we obviously have to change our policy and consider it beta until at least U3.&lt;/P&gt;</description>
      <pubDate>Mon, 30 Aug 2021 14:01:13 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/SD-Boot-issue-Solution-in-7-x/m-p/2864387#M277728</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2021-08-30T14:01:13Z</dc:date>
    </item>
    <item>
      <title>Re: vSAN All Flash performance troubleshooting</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-All-Flash-performance-troubleshooting/m-p/448163#M479</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;RAID controllers are HPE H240, firmware 5.04. What settings are you referring to?&lt;/P&gt;&lt;P&gt;6.0 U3 hosts are build 6921384.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kind regards, Vjeran&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 08 Mar 2018 13:30:28 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-All-Flash-performance-troubleshooting/m-p/448163#M479</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2018-03-08T13:30:28Z</dc:date>
    </item>
    <item>
      <title>Re: vSAN All Flash performance troubleshooting</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-All-Flash-performance-troubleshooting/m-p/448162#M478</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 ran all the proactive tests and tests with IOAnalyzer appliances (20 of them to get the parallelism) before putting any VMs on the datastore.&lt;/P&gt;&lt;P&gt;On the small clusters I got around 330 MB/s streaming writes with both tests, and on the larger cluster I got around 850 MB/s of streaming writes, i guess that is the test most relevant for migration and cloning operations. 330 MB/s seemed also low, but better than 100 MB/s..&lt;/P&gt;&lt;P&gt;Regarding latency, on most tests it was less than 10 ms (which also doesn't sound that great for an All-Flash system), it was much larger on tests with large block sizes, especially writes, of course.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kind regards, Vjeran&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 08 Mar 2018 13:28:40 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-All-Flash-performance-troubleshooting/m-p/448162#M478</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2018-03-08T13:28:40Z</dc:date>
    </item>
    <item>
      <title>vSAN All Flash performance troubleshooting</title>
      <link>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-All-Flash-performance-troubleshooting/m-p/448159#M475</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;We have 3 vSAN All Flash Clusters and the performance is not what we expected so I want to know how to troubleshoot if I have some configuration issues or we just expected too much (I excluded HW issues since we have the same situation on 3 clusters)..&lt;/P&gt;&lt;P&gt;All hosts are HPE Proliant DL380Gen9. Two clusters are 4 nodes, 2 disk groups of 7 capacity disks each, all SATA SSDs (those are clusters for test/dev VMs so we went with cheaper disks).&lt;/P&gt;&lt;P&gt;The third cluster is 8 node, also 2 disks of 7 capacity disks each. Capacity disks are SATA, Cache is NVMe.&lt;/P&gt;&lt;P&gt;vSAN network is using dedicated 10G interfaces. Everything is in HCL, health checks are green.&lt;/P&gt;&lt;P&gt;Two test clusters are on the latest 6.0 U3 build, the third cluster is on 6.0 U2, soon to be updated to the same build.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The two most noticable performance indicators are:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; -latency often goes over 100ms&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; -when moving VMs from FC SAN to vSAN or cloning VMs on vSAN, we get 100 MBps of throughput&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;On the small cluster we use RAID5, on the large one RAID6, dedup is enabled. I know those settings affect the performance, but still 100MBps looks low and latency is definitely too high?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Did we just expect too much, or is there something we can look at?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kind regards, Vjeran&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 06 Mar 2018 10:28:34 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-vSAN-Discussions/vSAN-All-Flash-performance-troubleshooting/m-p/448159#M475</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2018-03-06T10:28:34Z</dc:date>
    </item>
    <item>
      <title>Where can I find the Management Pack for vCloud Networking and Security</title>
      <link>https://communities.vmware.com/t5/VMware-Aria-Operations/Where-can-I-find-the-Management-Pack-for-vCloud-Networking-and/m-p/2740261#M17690</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;It seems that the Management Pack for vCloud Networking and Security has been removed from the Solution Exchange website.&lt;/P&gt;&lt;P&gt;Can I download it from somewhere else?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kind regards, Vjeran&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 19 May 2016 11:58:37 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/VMware-Aria-Operations/Where-can-I-find-the-Management-Pack-for-vCloud-Networking-and/m-p/2740261#M17690</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2016-05-19T11:58:37Z</dc:date>
    </item>
    <item>
      <title>Re: Centos virtual machine won't boot with 42 GB of RAM</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Centos-virtual-machine-won-t-boot-with-42-GB-of-RAM/m-p/2225752#M216378</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 am not sure if it is a VMWare or Linux issue.. I tried the same thing with a Windows VM and it works ok, but they also tried a Centos VM on KVM and it works ok..&lt;/P&gt;&lt;P&gt;And it's not like we have support for Centos to raise a case &lt;img id="smileywink" class="emoticon emoticon-smileywink" src="https://communities.vmware.com/i/smilies/16x16_smiley-wink.png" alt="Smiley Wink" title="Smiley Wink" /&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks anyway&lt;/P&gt;&lt;P&gt;Vjeran&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 26 Apr 2016 08:52:42 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Centos-virtual-machine-won-t-boot-with-42-GB-of-RAM/m-p/2225752#M216378</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2016-04-26T08:52:42Z</dc:date>
    </item>
    <item>
      <title>Re: Centos virtual machine won't boot with 42 GB of RAM</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Centos-virtual-machine-won-t-boot-with-42-GB-of-RAM/m-p/2225750#M216376</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;Thanks for your response.&lt;/P&gt;&lt;P&gt;No, I did not find a solution.&lt;/P&gt;&lt;P&gt;My environment is similar, but not identical: vCenter is 6.0 Update 1, ESXi is 5.5 Build 3343343, and linux kernel is 3.10.0-327.13.1.el7.x86_64.&lt;/P&gt;&lt;P&gt;Originally, openvmtools were installed, I tried with VMWare Tools (latest version) but there was no change.&lt;/P&gt;&lt;P&gt;Just to confirm, did you do guest os reboots (two in a row), either using VMtools or from "inside" the guest os? Because "hard" reboots work every time for me.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kind regards, Vjeran&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 25 Apr 2016 09:20:24 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Centos-virtual-machine-won-t-boot-with-42-GB-of-RAM/m-p/2225750#M216376</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2016-04-25T09:20:24Z</dc:date>
    </item>
    <item>
      <title>Re: Centos virtual machine won't boot with 42 GB of RAM</title>
      <link>https://communities.vmware.com/t5/ESXi-Discussions/Centos-virtual-machine-won-t-boot-with-42-GB-of-RAM/m-p/2225748#M216374</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;Openvm tools version 9.10.2 are installed. We tried installing VMWare Tools latest version (10.0.6), no change.&lt;/P&gt;&lt;P&gt;There are no resource pools, limits or reservations, also, there is no contention for memory on the host (around 40% memory used)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Kind regards, Vjeran&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 22 Apr 2016 19:21:16 GMT</pubDate>
      <guid>https://communities.vmware.com/t5/ESXi-Discussions/Centos-virtual-machine-won-t-boot-with-42-GB-of-RAM/m-p/2225748#M216374</guid>
      <dc:creator>vbabic</dc:creator>
      <dc:date>2016-04-22T19:21:16Z</dc:date>
    </item>
  </channel>
</rss>

