In my previous post, I covered the end-to-end migration of VMware NSX for vSphere to NSX-T Data Center (VMware NSX from v4.0.0.1) via the Fixed Topology Option, however, in real life I don’t see this option utilised very often due to the limited number of supported topologies.
How then can we achieve the same in-place, end-to-end migration of unsupported topologies? This is where the User Defined Topology option comes into play, and it offers much greater flexibility by enabling customers to define/map their own logical routing topologies. This, of course, will require a design and, like the message I tried to impart in my previous post, this must be planned ahead of your proposed change/maintenance/migration window.
In a previous post, we discussed the value of pre-migration validation checks, identifying whether a customer environment is aligned to the supported fixed topologies and the process of creating and viewing the JSON output following the successful import of NSX for vSphere configuration.
In this post, we continue on the same theme and will use the NSX-T (VMware NSX from v4.0.0.1) Migration Coordinator to migrate an NSX for vSphere environment, end-to-end, to NSX-T via the Fixed Topology option.
With VMware NSX for vSphere (NSX-V) having gone end of general support on January 16th 2022, there are numerous customers now busily working on migrating to VMware NSX-T Data Center (VMware NSX as of v4.0.0.1).
In future posts, I will detail the end-to-end migration process for both Fixed and User Defined Topologies utilising the NSX-T Migration Coordinator, however, before we jump in, let us look at a rather handy report which is often helpful in validating customer readiness and environmental health for those looking to migrate via the Fixed Topology option.
In my previous post (Veeam Backup & Replication – Part 1 – Building Replication Capabilities), we discussed offsite replication jobs using Veeam Backup & Replication v10. As per the Customer’s use case, we created a replication job to ensure a business-critical VM is replicated to a secondary site (Site B) in readiness for any unforeseen failures, planned maintenance, or downtime at the primary site (Site A).
This article discusses the failover and failback options available to us utilising Veeam Backup & Replication and, more importantly, when and where they should be used. We will then demo the failover process of our protected business-critical VM from Site A to Site B, and close by failing back live operations from Site B to Site A.
I recently ran into a small issue applying a patch to one of my lab’s vCenter Servers. Specifically, attempts to patch the vCenter Server ran into the error, Exception occurred in install precheck phase.
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 (administrator@vsphere.local, 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.
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.
Yesterday, Tuesday 16th October saw the much anticipated release of VMware’s vSphere 6.7 Update 1, however, shortly after the announcement a number of Veeam users decried the release due to compatibility issues with Veeam’s Backup & Replication suite. None other than Veeam’s Anton Gostev first announced the issue with the below tweet:
Looks like vSphere 6.7 Update 1 completely breaks backups, so please avoid updating until further notice. I must say I really miss those times when we didn’t even have to test vSphere updates, and literally supported them by default because they never broke anything – for years!
The very next day the Veeam team announced a workaround in the form of Veeam KB2784, as well as ‘out-of-the-box’ support being included with highly awaited (and much delayed) next release, Update 4.
vSphere 6.7 U1 compatibility issue has been researched, and the simple workaround is now available for use in test labs. Official out-of-the-box support for vSphere 6.7 U1 will be included in Update 4. See this Veeam forums topic for more details > https://t.co/BNgMNWDOmS
Where the fault lies with such release/compatibility issues is not the goal of this post (which Twitter seems to be more focused on). However, with a high number of pros likely raising internal changes to upgrade their vCenter(s) and ESXi hosts, you’ll want to implement the Veeam workaround in-line with this upgrade, as well as a number of solid backup/restore tests.
Not only will this year mark my first ever visit to VMworld Europe, I’ll also be taking part in a Customer Panel session.
If you are interested in hearing my VMware NSX Data Center journey, how we implemented and operationalised NSX; how NSX continues to increase security and application performance, while simplifying troubleshooting and improving network provisioning time, then join me on Thursday, 8th November at 12:00-13:00 to hear more.
You may have noticed that your usual Active Directory user account (which might afford you full administrative access in vCenter) doesn’t get you very far when attempting to manage NSX for vSphere. This is by design, as NSX access is not governed or controlled by vCenter Server roles.
NSX utilises it’s own predefined security roles for role based access, all of which can be assigned to Active Directory Users and/or Security Groups. This is great for larger teams with clearly defined areas of demarcation and responsibilities, smaller teams of administrators and read-only support teams, and even one-off auditor visits.
In this post, I detail the procedure for implementing AD integration in VMware NSX for vSphere 6.4.2, however, the procedure is the same for NSX 6.X. Before we start, let’s take a look at the six NSX Security Roles:
NSX Security Roles
Auditor – Users in this role can only view system settings and auditing, events and reporting information and will not be able to make any configuration change.
Security Engineer – Users in this role can perform all security tasks, such as configuring policies and firewall rules. Users have read access to some networking features, but no access to host preparation and/or user account management.
Network Engineer – Users in this role can perform all networking tasks, such as routing, DHCP, bridging, etc. Users have read access to endpoint security features, but no access to other security features.
Security Administrator – Users in this role can configure security compliance policies in addition to viewing the reporting and auditing information in the system.
NSX Administrator – Users in this role can perform all tasks related to deployment and administration of this NSX Manager instance.
Enterprise Administrator (God Mode) – Users is this role can perform all tasks related to deployment and configuration of NSX products and administration of this NSX Manager instance.
Procedure
Please note, due to current feature parity differences between the vSphere Web Client (Flex) and vSphere Client (HTML 5), the below procedure will need to be performed utilising the vSphere Web Client (Flex).
1. Create your required AD Security Groups, naming accordingly.
2. Log in to the vSphere Web Client (Flex) as administrator@vsphere.local.
3. Browse to Networking & Security > System > Users and Domains.
4. Via the Users tab, click the Add icon.
5. Select Specify a vCenter group and enter the AD Security Group name as per above AD Objects. When ready, click Next.
6. Select the appropriate NSX Security Role to associate with the AD Security Group and click Finish.
7. Repeat steps 4 – 6 until all required AD Security Groups have been added.
8. Confirm successful addition of all NSX Security Roles. At this point, you can assign further AD Users/Security Groups, disable or enable accordingly, and delete.
9. Log in to either the vSphere Web Client or vSphere HTML5 Client as a user associated to one of the newly added AD Security Groups and test access. Below I detail an example of both Auditor and Enterprise Administrator roles.
Here, the user is assigned the NSX Auditor Security Role.
Here, the user is assigned the NSX Enterprise Administrator Security Role.
