After upgrading to vCenter 7 Update 1 , when I tried to browse vCenter HTML5 UI, I faced “no healthy upstream” error. I could access to vCenter Management Interface (VAMI) https://vCenter-IPaddress:5480 without any issues. I could also connect to vCenter Server through SSH but I realized couple of vCenter Server services could not start.
In the previous blogpost we went through Azure VMware Solution(AVS) IPSec VPN setup and to complete hybrid networking between on-prem and AVS we need to configure NSX-T gateway too. As we discussed the target architecture would look like the following diagram.
When it comes to connecting an on-premises VMware environment to Azure VMware Solution(AVS), ExpressRoute is the preferred connectivity method. But in some cases using a VPN tunnel is the preferred connectivity method to AVS environment.
NSX-T Tier-0 or Tier-1 gateways could be used to connect on-premises VMware environment to AVS. On the Azure side, Virtual WAN(vWAN HUB) will be provide the transit connectivity through a ExpressRoute Gateway into AVS infrastructure. I am going to walk you through the configuration of both NSX-T Tier-1 GW and Azure Virtual WAN to have a complete setup.
Starting with version 4.7.100, VxRail supports vSAN 2-Node for small and Remote-Office Branch-Office (ROBO) deployments. This solution works best for environments that needs hyperconverged compute and storage with a minimal configuration. VxRail 2-Node consists of two VxRail E560 nodes and a vSAN Witness Appliance. It is recommended to deploy the Witness appliance in another site but in case of lacking another site it can be deployed in the same site as vSAN 2-Node.
There are some considerations and requirements that you need to have it in place before starting the VxRAIL 2-Node implementation.
Continue reading “VxRail 2-Node Implementation Considerations (VxRail 7.0.100)”When it come to setting up a hybrid cloud environments, one of the most important topics is networking. It is usually comes down to stretch on-prem network segments to the public cloud environment. This blog post is going to simply describe NSX-T architecture on AVS as the default networking and security stack. If you are new to AVS you can read Introduction to AVS blog post first, and then continue with this article.
vSphere 7.0 introduced by VMware in March 2020 and went to GA in April 2020. Many new features like DRS & vMotion improvement and also Lifecycle Manager has been released. After half a year VMware introduced first major update on vSphere 7 and today this release went into GA. It is now publicly available, you can download it from VMware and take advantage of this latest and greatest release! Here in this blog post I will go through the new features and capabilities
On September 22nd 2020, during Ignite 2020 , Microsoft announced the general availability of next generation of VMware Azure Solution(AVS). If you want to learn about basics of AVS, you can read my previous blog post on Introduction of Azure VMware Solutions. Now AVS is now generally available in four Region at US East, US West, West Europe (Netherlands) and Australia(NSW). AVS also going to be available in Japan East, UK South and South Central US in the near future. You can check the availability of Azure VMware Solution by checking Azure Products by Region page for details.
Azure VMware Solution (AVS) enables you to run VMware SDDC stack natively on Azure to build-up a hybrid cloud infrastructure. AVS is a VMware validated solution that being delivered by Microsoft on Azure environment. According to Microsoft’s release statement in May 2020, “You can provision a full VMware Cloud Foundation environment on Azure and gain compute and storage elasticity as your business needs change”. Popular scenarios for this solution are datacenter footprint reduction, On-demand datacenter expansion, disaster recovery & business continuity and finally application modernization.
In Part 1 of NSX-T SSL Certificate Replacement, the process of certificate template preparation and request has been explained. This blog post will teach you how to import and replace the generated certificate into NSX-T Manager. It is really important to verify the imported certificate before replacing it. I want to point out that if you are using a Virtual IP for you NSX-T management cluster, you should have generated the SSL certificate for management cluster’s Virtual IP address.
NSX-T installation comes with a out of the box self-signed SSL certificate. Because of security and compliance reasons, most of customers want to replace default self-signed certificate with a CA signed certificates. We have been looking for guide that explains how to do this step-by-step but unfortunately we couldn’t find one! There are some very useful guides like this one from VMware but as you read through, you realize the documentation is not complete. So to make story short, we looked around and ran SSL certification replacement.