For those coming from an NSX-V background, you’ll remember how we enabled east-west traffic by deploying Distributed Logical Routers (DLR). This has changed ever so slightly in NSX-T, with earlier versions using Tier-1 Logical Routers, and in 2.4, Tier-1 Gateways.
That didn’t disappoint! I’ve wanted to visit the North East England VMUG for sometime, so being asked to present at the user group made it all the more special. As I sit here in Newcastle International Airport waiting for my flight home, I thought I’d summarise the event for those who’ve never been to a VMUG event, are thinking of doing so in the future, or are thinking of speaking at a local VMUG.
vSAN deployments in brownfield environments are simple. New hosts are configured based on projected workloads (plus points for utilising vSAN Ready Nodes), they’re purchased, racked, built, and absorbed into an existing vCenter workload domain before vSAN is finally enabled and configured. But how would we deploy vSAN into a greenfield environment? An environment with no vCenter, no shared storage, but only brand new ESXi hosts with valid (yet unconfigured) cache and capacity vSAN disks? As vSAN is reliant on vCenter for its operations, we seemingly have a chicken-and-egg scenario.
In this article, I detail the process of deploying (Stage 1) and configuring (Stage 2) a vCenter Server Appliance into a greenfield environment and, more specifically, onto a single-node vSAN cluster in hybrid-mode (Note – this is in no way supported by VMware for anything other than deploying vCenter and vSAN into a greenfield environment). I then add additional hosts to the cluster and configure vSAN storage and networking via the brilliant Cluster Quickstart tool (Stage 3), before applying a vSAN VM Storage policy to the vCenter Server Appliance (Stage 4). Once complete, our vSAN cluster will be ready to host live workloads.
The On-Demand Library for this year’s VMworld in San Francisco is now live with all sessions available to stream. Simply visit the VMworld 2019 On-Demand Library and enjoy!
The next North East England VMUG will be taking place on Thursday 26th September at the Royal Station Hotel, Newcastle, and I’m excited to be presenting alongside so many fantastic individuals from throughout the vCommunity.
My session will be covering VMware NSX Data Centre for vSphere (NSX-V) and, more specifically, a real world look at micro-segmentation and the implementation of a zero-trust environment. NSX makes this fairly easy thanks to a number of built-in tools, and we’ll explore how we can use the NSX Application Rule Manager to visualise application dependencies in order to start fleshing-out our Distributed Firewall rules.
Patching my lab’s vCenter Server Appliance this evening raised an issue whereby the root password had expired. Unable to login via root, I can still administer the appliance via a vCenter’s SSO domain account (firstname.lastname@example.org, for instance), however, attempts to perform any updates will not be possible until the appliance’s root account password is reset. This an easy exercise, however, this is not possible via vSphere UI or console, only bash.
VMware NSX Data Center for vSphere (NSX-V) has been able to leverage dynamic routing via Open Shortest Path First (OSPF) and Border Gateway Protocol (BGP) for some time and, in this article, I detail the process of configuring OSPF on both an Edge Services Gateway (ESG) and a downstream Distributed Logical Router (DLR).
OSPF, a Link State Protocol and member of the Interior Gateway Protocol (IGP) family (which also includes Routing Information Protocol (RIP), Intermediate System to Intermediate System (IS-IS), and Enhanced Internal Gateway Routing Protocol (EIGRP)), enables all participating routers to dynamically exchange network topology information to calculate the best shortest path (cost) of a route’s destination.
Twice each year VMware’s vExpert program opens its doors to applications throughout the IT and tech community. That second door opened just recently on June 7th 2019. The vExpert community is a group of like-minded enthusiasts, bloggers, book authors, VMUG leaders, speakers, tool builders, and community leaders.
If you are already busy in the community and are contributing in some way, this will without doubt open doors for you, give you priority access to VMware information and, of course, there are the usual vExpert licensing benefits.This has opened a huge amount of doors for me over the past two years, and has been a key driver in forming a number of fantastic relationships and creating some amazing opportunities. In my eyes, the VMware community in general is the most amazing community out there. Full of amazing, knowledgeable people, so why not join in?
For those already consuming Microsoft Office 365, then you will undoubtedly (to some level) be utilising Azure Active Directory. Azure AD comes with an array of tools, some of which aren’t confined to public cloud; some can even aid and strengthen your on-premises applications. One such tool is the Azure Multi-Factor Authentication Server, an on-premises 2-factor authentication mechanism which can integrate with on-prem VMware Horizon environments.
The Azure MFA Server enables us to further enhance the security of numerous applications capable of integrating with 2FA authentication, and VMware Horizon has been able to integrate with such solutions for some time. This additional level of security is a much sought after function which serves to further secure public access to internal desktop pools.
Welcome to the second article in the series detailing a migration of VMware NSX Data Center for vSphere (NSX-V) to NSX-T Data Center. In this article I focus on the preliminary checks to ensure the NSX-V environment is fit for migration.
In part 1 (VMware NSX-T Data Center Migration – Part 1 – Deploy Manager Appliance) I covered the process of deploying the NSX -T Data Center Manager Appliance, as well as a number of prerequisite tasks required to prepare the new NSX-T environment for the eventual migration (coming in part 3).
In this article I detail a number of preliminary checks within the NSX-V environment (including ESXi hosts, vSphere Distributed Switches, VXLAN configuration, VTEP, NSX Controllers, Edge Services Gateways, etc.) to ensure all is well prior to the migration process itself. Where any issues are identified, these must be resolved prior to the migration process.