WilliamLam.com

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

by // 5 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.

https://twitter.com/trodemaster/status/1234999442991800320

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!

Big updates to the vCenter Event Broker Appliance (VEBA) Fling

by // 1 Comment

The vCenter Event Broker Appliance (VEBA) team has been working hard over the last couple of months on some pretty exciting enhancements and today we are pleased to announce the release of VEBA v0.3 which can be download from the VMware Fling site. Although this is a "dot" release, do not let that fool you as this release contains a large number updates including a major re-architecture in how events are consumed and processed at the core of VEBA.

While this re-architecture does introduce some breaking changes, it does unlock a number of new capabilities that our current users have been asking for. It also provides us with a solid foundation for delivering on future enhancements such as multi-vCenter Server support and additional event sources from NSX-T, vSAN and other VMware Cloud Services to just name a few. Today, the "V" in VEBA stands for vCenter, but in the future, I do see it changing to just "VMware" as it can support so many other solutions.

Having said that, some of the breaking changes also improves the overall user experience, especially as it relates to defining and consuming vCenter Server events as well as troubleshooting and debugging. The team is super excited to get this release in the hands of our community and we look forward to hearing your feedback!

What's New:

  • Introduction of the VMware Event Router which provides a modular and flexible architecture for decoupling the stream "Providers" such as vCenter Server from the actual stream "Processors" like OpenFaaS. More details including its architecture and design can be found here

[Read more...]

Automating the creation of NSX-T "Disconnected" Segments for DR testing on VMware Cloud on AWS 

by // 1 Comment

Disaster Recovery (DR) and Disaster Avoidance (DA) on VMware Cloud on AWS is still one of the most popular use case amongst our customers, just second to Datacenter Migration and Evacuation. The VMware Site Recovery service makes it extremely easy and cost effective for customers to protect their critical workloads without having to worry about the underlying infrastructure. Most often, the biggest cost of having a dedicated DR site is the on-going operational and maintenance cost of that infrastructure.

Most recently I have seen several requests come in where customers were looking to streamline their DR testing which is fantastic to hear. Just having a DR solution is not enough, you actually need to exercise it and verify that your workloads and applications are functioning as expected. Today, customers can verify that their applications are functioning as expected by creating NSX-T network segments that are "Disconnected" and then using a VM-based router to provide internal connectivity between these isolated environments.

Here is a screenshot of the VMware Cloud console and under the Networking & Security tab, when creating a new segment you can specify whether the segment is "Connected" (Routed) or "Disconnected".


Obviously, the NSX-T UI is just one way of creating a segment. In fact, most customers that have asked about this is wanting to do this via Automation which not only brings speed to testing but also consistency! With that, I have updated my NSX-T PowerShell Community Module for VMC to include two new updates. If you have never used this VMC module before, please take a look at the Getting Started guide here.

[Read more...]