virtuallyGhetto

Home Lab

Configure NSX-T Edge to run on AMD Ryzen CPU

by 1 Comment

The vast majority of VMware Homelabs is still Intel-based today but I have been seeing a slow rise of AMD-based kits being adopted, especially with AMD's desktop line of CPUs known as Ryzen. One of the considerations on whether you could use an AMD processor was whether you were planning to deploy NSX-T and in earlier releases, only Intel was supported as the NSX-T Edge required support for Data Plane Development Kit (DPDK) and this was only supported with Intel-based processors.

With the latest NSX-T 3.0 release, AMD-based processors are now supported and per the release notes, the following CPUs can be used:

  • AMD EPYC 7xx1 Series (Naples)
  • AMD EPYC 3000 Embedded Family and newer
  • AMD EPYC 7xx2 Series (Rome)

You will notice that only AMD's server line of CPUs known as EPYC are currently supported, which makes sense for running Production workloads. If you attempt to deploy an NSX-T Edge Node running on a non-EPYC platform, you will get an error message stating the CPU is not supported and I figured this was probably due to the lack of DPDK support in the consumer CPUs.

Yesterday, in our internal "Homelab" Slack channel, I came across an interesting tidbit from Andrea Spagnolo, a Sr. Field Engineer in our Cloud Native Business Unit who shared a pretty neat trick on how to get latest NSX-T 3.0 release to work with a Ryzen-based CPU.

Disclaimer: This is not officially supported by VMware. The behaviors described here can change in the future

First off, I want to thank Andrea for sharing but also credit to Beniamino Guarnaschelli and his blog post here which actually gave Andrea the idea to take a closer look as he was trying to get this setup in his own personal homelab.

[Read more...] about Configure NSX-T Edge to run on AMD Ryzen CPU

Changing the default size of the ESX-OSData volume in ESXi 7.0

by 7 Comments

In ESXi 7.0, a new partition scheme was introduced which also brings along a new set of storage requirements. These changes are explained in the official documentation here and the following VMware KB 77009 also contains some additional info which can be helpful. Storage changes are not easy but this was necessary to not only better support some of the current capabilities but more importantly, it setups the foundation for future ESXi capabilities.

The biggest change to the partition layout is the consolidation of VMware Tools Locker, Core Dump and Scratch partitions into a new ESX-OSData volume (based on VMFS-L). This new volume can vary in size (up to 138GB) depending on a number of factors including the current ESXi boot media (USB SD-Card, Local Disk) but also the size of the device itself, which is explained in the official documentation.

From some of the comments on Twitter, Reddit and the direct inquiries that I have received, this new behavior seems to be most impactful to smaller homelabs where a fresh install of ESXi 7.0 has been performed. Folks have shared that their ESX-OSData volume has taken up 120GB which can be quite significant if you have a smaller disk which can be quite common. I normally install ESXi on a USB device and I also use vSAN, which has a different behavior and I have also not upgraded my physical ESXi host (E200-8D) to 7.0 yet.

I performed a fresh installation of ESXi 7.0 (running as Nested ESXi VM) that was configured with 1TB of storage and here is what the filesystem layout now looks:


We can see that the ESX-OSData volume takes up ~119.75GB, which is not too bad for 1TB volume but I can understand this may not be ideal if you have something smaller such as 250GB to 512GB disk. Due to the size of the local device, the boot options mentioned in the KB would not be helpful and I was curious myself if this ESX-OSData volume size could be configurable. In doing some research it looks like the size of the ESX-OSData can be specified using the following ESXi boot option (SHIFT+O during the initial boot) called autoPartitionOSDataSize

Disclaimer: This may not be officially supported by VMware as it deviates from the system defaults and can have other unintended behaviors. Use at your own risk.

[Read more...] about Changing the default size of the ESX-OSData volume in ESXi 7.0

Quick Tip – Allow unsupported CPUs when upgrading to ESXi 7.0

by 21 Comments

As outlined in the vSphere 7.0 release notes (which everyone should carefully read through before upgrading), the following CPU processors are no longer supported:

  • Intel Family 6, Model = 2C (Westmere-EP)
  • Intel Family 6, Model = 2F (Westmere-EX)

To help put things into perspective, these processors were released about 10 years ago! So this should not come as a surprise that VMware has decided remove support for these processors which probably also implies the underlying hardware platforms are probably quite dated as well. In any case, this certainly has affected some folks and from what I have seen, it has mostly been personal homelab or smaller vSphere environments.

One of my readers had reached out to me the other day to share an interesting tidbit which might help some folks prolong their aging hardware for another vSphere release. I have not personally tested this trick and I do not recommend it as you can have other issues longer term or hit a similiar or worse situation upon the next patch or upgrade.

Disclaimer: This is not officially supported by VMware and you run the risk of having more issues in the future.

Per the reader, it looks like you can append the following ESXi boot option which will allow you to bypass the unsupported CPU during the installation/upgrade. To do so, just use SHIFT+O (see VMware documentation for more details) and append the following:

allowLegacyCPU=true

There have also been other interesting and crazy workarounds that attempt to workaround this problem. Although some of these tricks may work, folks should really think long term on what other issues can face by deferring hardware upgrade. I have always looked at homelab as not only a way to learn but to grow yourself as an individual.

Note: The boot option above is only temporarily and you will need to pass in this option upon each restart. It looks like this setting is also not configurable via ESXCLI which I initially had thought, so if you are installing this on a USB device, the best option is to edit the boot.cfg and simply append the parameter to kernelopt line so it'll automatically be included for you without having to manually typing this. If this is install on disk, then you will need to edit both /bootbank/boot.cfg and /altbootbank/boot.cfg for the settings to passed in automatically.

This is ultimately an investment you are making into yourself, so do not cut yourself short and consider looking at a newer platform, especially something like an Intel NUC which is fairly affordable both in cost as well as power, cooling and form factor.

Special VMUG Advantage Homelab Group Buy

by 8 Comments

The VMware Community Homelabs Project is a crowdsourcing effort that I had started back in February that enables the VMware community to help share the various VMware homelab configurations, usage and costs into a single location that can benefit our larger community. With the success of that project and the "hardware" aspects out of the way, I wanted to see what else I could do to help our VMware community in terms of the "software" aspects, as that is just as important.

The most popular solution by far today is to sign up for a VMUG Advantage membership which gives you access to a number of benefits including training and VMworld discounts but also to EVALExperience, which provides you with 365-days access (non-production usage) to the latest VMware solutions such as vSphere, vSAN, NSX, vRealize Suite and VMware Cloud Foundation. The EVALExperience alone is worth the $200 USD membership and is certainly one of the cheapest and easiest way to get access to all the latest VMware offerings for homelab purposes. Throughout the year, there are usually promo codes that you can find that ranges anywhere from 5-10% discount, but I wanted to see if we could do better 🙂

Today, I am very excited to announce a partnership between virtuallyGhetto and the VMware User Group (VMUG) organization to share with the VMware Community a special VMUG Advantage Homelab Group Buy offering. The table below provides the respective discounts based on the quantity of VMUG Advantage membership purchases. The larger the interests group, the larger the discount.

UPDATE (04/25/20) - The survey has officially closed and I will send in the final list to the VMUG folks which you will be receiving an email with instructions on how to obtain your promotional code. In total, we had a total of 701 respondents!


UPDATE (04/20/20) - We now have over 600+ folks registered. Everyone signed up (please sign up as that is the only way to take part in the group buy) will receive the 15% discount. I have already spoken to the VMUG folks and they will be working on getting the promotion code ready so folks can start purchasing immediately, stay tuned for that update via email. We have also agreed to leave the survey up for another week (Fri 4/24 will be last day) to ensure that everyone has the opportunity to sign up.

Quantity Discount Cost
1-99 12% $176
100-199 14% $172
200-300 15% $170

With the GA of vSphere 7.0, vSAN 7.0 and NSX-T 3.0, there is no better time to consider VMUG Advantage to get access to the latest releases. If that was not enough, I should also mention that VMUG Advantage will also include the upcoming VMware Cloud Foundation 4.0 release, which will allow folks to also try out the new vSphere with Kubernetes capabilities, which is currently only available as part of the VMware Cloud Foundation SKU.

Note: Licenses from VMUG Advantage can NOT be used for Production purposes.

If you are interested in participating in the VMUG Advantage Homelab Group Buy, please fill out the following survey below to express your interests in purchasing a VMUG Advantage subscription(s). This survey is planned to be open for two weeks to gauge the level of interests and help determine the final promotion discount. Please share this with friends and colleagues and its never too early to start thinking about Christmas gifts for that special someone 😉

Once the survey period has closed, you will be contacted by the VMUG organization with the details of the promotion along with the promotion code to apply towards your VMUG Advantage membership. Depending on the amount of interests, we could potentially close the survey sooner if we reach 200+ folks.

Here's short URL for the survey in case you want to share with others: http://vmwa.re/vmug-adv-groupbuy

Homelab considerations for vSphere 7

by 69 Comments

With the vSphere 7 Launch Event just a few days away, I know many of you are eager to get your hands on this latest release of vSphere and start playing with it in you homelab. A number of folks in the VMware community have already started covering some of the amazing capabilities that will be introduced in vSphere and vSAN 7 and I expect to see that ramp up even more in the coming weeks.

One area that I have not seen much coverage on is around homelab usage with vSphere 7. Given this is a pretty significant release, I think there are some things you should be aware of before you rush out and immediately upgrade your existing homelab environment. As with any vSphere release, you should always carefully review the release notes when they are made available and verify the hardware and its underlying components are officially on the VMware HCL, this is the only way to ensure that you will have a good and working experience.

Having said that, here are just a few of the observations that I have made while running pre-GA builds of vSphere 7 in my own personal homelab. This is not an exhaustive list and I will try to update this article as more information is made available.

Disclaimer: The following considerations below is based on my own personal homelab experience using a pre-GA build of vSphere 7 and it does not reflect any official support or guidance from VMware. Please use these recommendation at your own risk.

[Read more...] about Homelab considerations for vSphere 7

Sonnet Solo5G Multi-Gig (1G/2.5G/5G) USB Adapter works with ESXi

by 2 Comments

Last week I caught this tweet from Blake Garner who is an active VMware Community member that I follow and I came to learn that Sonnet just launched their first Multi-Gigabit (1GbE, 2.5GbE & 5GbE) USB Network Adapter called the Solo5G.

This of course piqued my interest for VMware Homelabs as last year we had just enabled the first Multi-Gigabit USB Network Adapter from QNAP supporting ESXi using the popular USB Native Driver Fling for ESXi. The QNAP device uses an Aquantia chipset and I had a funny suspicion that the Sonnet device might be using either the exact same or simliar chipset.

To confirm my theory, I reached out to the folks over at Sonnet and they were kind enough to send me a unit for validation which just arrived earlier this week. I had an Intel NUC 10 (Frost Canyon) already running and I just plugged it in and to my surprise it worked immediately since it already had the USB Native Driver Fling installed.


So there you have it, same chipset as the QNAP and best of all this device is only $79.99 USD which be purchased directly from Sonnet here. As of writing this blog post, the Solo5G is much cheaper than the QNAP. In fact, it seems the price of the QNAP has significantly increased since I had first blogged about it. I think multi-gig NICs both USB-based but also PCIe and respective switches is starting to become more mainstream, at least in the consumer markets and this is certainly an easy way to add additional bandwidth without breaking the bank. Big thanks to the folks at Sonnet and Blake for sharing the news!