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.
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!
— Anton Gostev (@gostev) October 16, 2018
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
— Anton Gostev (@gostev) October 17, 2018
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.
To register for the session, simply visit the VMworld 2018 Europe Content Catalogue – Customer Panel on NSX Data Center (NET3042PE).
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.
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 email@example.com.
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.
Thursday 14th June saw the latest London VMUG take place at Tech UK, London, with the User Group marking it’s third outing for 2018 in just six months! Rarely does any event see such heavy hitters as Duncan Epping, Frank Denneman, and Niels Hagoort in one place, but today, we got to see all three in attendance. Add to that line-up further awesomeness in the form of vCommunity member, Chris Porter, and this was one truly great London VMUG indeed! I’ve been to a number of VMUGs around the UK, however, this was to be my first time joining the London gang.
By design, there are certain virtual machines and/or appliances within vSphere which are protected to prevent editing (this can include NSX Controllers, Edges, Logical Routers, etc.) In a live/production environment, you’d not normally care about editing these appliances, however, in a lab environment (especially one where resource is tight), reducing memory and/or CPU allocation can help a lot. As such, this article will cover the process of removing the lock on protected VM in vSphere, in order to enable editing.
The scenario: a customer needs to reduce the resource allocation of an NSX Controller, however, due to the VM in question being protected/locked, editing the VM’s resources is not possible via UI or PowerCLI.
The process of removing this lock is quick and easy, however, we first need to identify the virtual machine’s Managed Object Reference (moRef ID). Please note, VMware do not support or recommend this procedure in any way. As such, this procedure should not be implemented in a production environment.
In Part 1 of this series we covered the simple installation and configuration of VMware vRealize Log Insight. In Part 2 we will cover how we can further configure and customise Log Insight via Content Packs in order to leverage further logging capabilities.
As mentioned in Part 1, one of the caveats of utilising this ‘free’ version of Log Insight (or more aptly, the 25 OSI license available to all vCenter Server licensees), is the ability to use VMware-only Content Packs. This is far from a bad thing and, as a result, enables us to integrate with other VMware products including NSX, Horizon, SRM, etc. In this article we will focus on the former product.
If, like most of us, you forward vCenter and ESXi host Syslog data to centralised Syslog targets (and if you don’t, then I’d advise you do), then you’ll be pleased to hear that (as long as you have a valid vCenter Server license) you’ll be able to utilise the power of VMware vRealize Log Insight to interrogate this data.
This article will be the first in a two part VMware vRealize Log Insight series, the first of which will detail the simple installation and configuration process, with the second article focusing on advanced configuration and integration with VMware NSX via vRealize Log Insight Content Packs (vRealize Log Insight add-ins enabling further integration with both VMware and 3rd party products).
If you’ve somehow managed to miss these brilliant (and free) VMware NSX guides, then worry not, as here are the links in all their glory. I cannot praise these books enough. Simply brilliant (and free!)
VMware NSX Micro-segmentation Day 1, by Wade Holmes
In Day 1, Wade Holmes details the migration away from a perimeter-orientated approach, to that of a micro-segmented architecture. VMware NSX enables organisations to utilise enhanced security functionality, whilst visualising traffic within the software-defined data centre.
VMware NSX Micro-segmentation Day 2, by Geoff Wilmington
In Day 2, Geoff Wilmington complements the first guide by delving deeper into micro-segmentation, and details the process of both building and planning an architecture best suited to your applications. Also touched on are the additional tools such as VMware Log Insight, Application Rule Manager, and vRealize Network Insight.
From a personal point of view, the process of planning the migration of applications into NSX was a little daunting during my own implementation, and this guide has been simply invaluable.
Operationalizing VMware NSX, by Kevin Lees
In Operationalizing VMware NSX, Kevin Lees discusses how best to bring VMware NSX into ‘business as usual’. Both monitoring and troubleshooting are covered, and insights into team structures and cultures, team roles and responsibilities, etc., are provided. Unlike the ‘how-to’ style of the first two books, this third guide provides a fantastic insight into how NSX can be brought into service.
Automating NSX for vSphere with PowerNSX, by Anthony Burke
Lastly, Automating NSX for vSphere with PowerNSX by Anthony Burke will be a firm favourite for all PowerShell fans wanting to get down and dirty with NSX.