VMware

Recently I was playing around with NSX-V in the lab and getting myself more familiar with the automation options available. During the deployment of one of my environments, I couldn’t get the NSX Controllers to come up without failing. NSX Manager would deploy the controller VM, but it sat in a “deploying” state for around 45 minutes and then failed with a message “no route to host”. I checked out the console of one of the controllers directly after deployment and as soon as it booted up it went to the following GRUB boot loader screen:

That title is a bit of a mouthful, but it’s Friday night and that’s the best I’ve got! I was recently working through some recovery scenarios for NSX in the lab, as I was interested to understand what the process was for various scenarios such as: Losing NSX Manager and restoring Losing NSX Manager, DLR and ESG’s and restoring Losing the entire cluster (including ESXi hosts) and restoring NSX manager in to a new cluster The third scenario is reasonably obscure, and I’m not sure if you would follow a different restore process than what I did if this did actually happen.

This one will be a quick post, but I wanted to alert people to a new minor but useful feature that’s included in the vCenter 6.7 appliance, which is the ability to schedule backups natively within the appliance management interface. If you wanted to schedule an appliance based backup in 6.5, you would have to schedule a task to do so. Thankfully this was made easier by Brian Graf’s script, but now we have a way to build this in to the appliance configuration with no reliance on an external script.

[toc] Introduction Starting from VMworld US 2017, VMware announced their plans to support PSC replication and Enhanced Linked Mode with the vCenter Embedded deployment model, simplifying overall deployment and management requirements for a multi-vCenter environment. This feature is now included in the release of vSphere 6.7. In this post, I go over a little history for common deployment models, as well as what the new “vCenter Embedded Linked Mode” brings to the table.

It’s back, finally! A new feature with vCenter 6.7 is the ability to repoint a vCenter Server to another Platform Services Controller node, that resides in an entirely different vSphere SSO domain. This functionality is huge for domain consolidation, and also domain splitting (which admittedly is a less required use case from what I’ve seen, but something that still can be a useful use case). Edit: As per a comment from Rupak, I believe this feature is only available on the vCenter Server Appliance and is not available for the Windows deployment of vCenter 6.

Well, it’s that time of the year again. The VMware User Group (VMUG) UserCon’s are on again this week in Sydney (Tuesday 20th March) and Melbourne (Thursday 22nd March), Australia. VMUG UserCon is a free day long event filled with a few keynotes, breakout sessions, networking and checking out the exhibit hall. I’ve personally only attended one UserCon, which I wrote about here, but I was really impressed at the organisation and presence from VMware, sponsors and community members.

So that title is a mouthful, but I came across an issue for a customer today where network mappings within SRM were not functioning correctly when attempting to configure protection for virtual machines. To cover this off quickly, the environment is running vSphere 6.0U3 and SRM 6.1.2. The scenario was that we’d previously (a few months ago) configured all of the mappings in SRM (Network, resource, folder, etc). We then created a new protection group, and created a recovery plan for this particular protection group.

I was recently rolling out the base install of VMware NSX in my lab, where I ran in to a controller deployment issue. The lab is running NestedESXi, and I have two ‘sites’ that are nested, each with 3 ESXi hosts in a vSAN cluster. vCenter, PSC and NSX Manager / controllers are then deployed on to the nested ESXi hosts, so the storage is on the nested vSAN datastores.

I’ve recently been doing a lot of work in my home lab, which has involved me moving from a flat /24 network (yeah, I know) to a somewhat more realistic lab environment with a Cisco SG300 switch and Ubiquiti EdgeRouterx. Due to these networking changes, as I build out the environment I’ve been creating a lot of VLANs and subnets between my physical ESXi host, the Cisco switch and the ERx.

For those that weren’t aware, vRealize Infrastructure Navigator went End of Distribution (EOD) and End of Support Life (EOSL) at the end of September, 2017. Information on this is provided in another post. If you are not aware of what vRealize Infrastructure Navigator (VIN) was, it was a tool that was part of VMware’s vCloud Suite that discovered application dependencies and mapped network flow within a vSphere environment. VIN was deployed as a virtual appliance and then registered with vCenter Server.