Today, we’re pleased that VMware was once again named a Leader in the 2018 revision of the Gartner Magic Quadrant for Hyperconverged Infrastructure (HCI), improving on both the Completeness of Vision and Ability to Execute axes. VMware believes this is a validation not only of our strategy, but also our ability to execute on our The post VMware Once Again a Leader in the Gartner Magic Quadrant for Hyperconverged Infrastructure, November 2018 appeared first on Virtual Blocks.
VMware is pleased to announce that, for the third year in a row, vSAN is the CRN Product of the Year in the Software Defined Storage category. We are thankful for the recognition from our partner community, and we’re excited to see the continued leadership momentum. This year, vSAN was named a leader twice by The post For Three Years Running, VMware vSAN named the CRN Product of the Year in the Software Defined Storage Category! appeared first on Virtual Blocks.
Hola! It’s been some time that I have written on my blog.
Recently I was working with one of my customers with a Private Cloud Deployment based off vRA 6.2.3 and the associated vRealize Suite Advanced products. With vRA 7.3 being GA’d last month, I made the customer aware of the features and benefits of vRA 7.3 and he was awed. I was quickly tasked to help setup a PoC environment and showcase the benefits to the Business. We were lucky to get the blessings from the Business to take this forward and plan for the Upgrades.
There are tons of improvements in the 7.3 release especially when you are running off 6.2.x in your environment.I am not going to brag about the features and benefits of vRA 7.3(even though I would love too!), there are a good number of blogs already on this, but what I am here to talk about is the Upgrade Assist Tool, which would help plan the upgrades.
Back in the olden days, when it was just vSphere , things were pretty simple and so were the upgrades. But now, with so many components talking to each other, upgrades require a good amount of planning.
This customer of mine had been through the upgrade process of upgrading their distributed vRA deployment from 6.2.1 to 6.2.3 and were worried since the 7.3 release would be a major change and wanted us to ensure we do not miss out on any steps while planning the same.
Thanks to the Cloud Management Business Unit team at VMware, who have helped create this vRealize Automation Upgrade assist tool found in the Upgrade Center , see https://www.vmware.com/in/products/vrealize-automation/upgrade-center.html to make things easier and smooth.
Ok, so let’s get to the meat.
The vRealize Automation Upgrade Assist Tool can be downloaded from the Upgrade Center and of course has a guide associated with it for you to follow. If you have used the vRealize Production Test Tool in the past, this would be somewhat familiar (& also feel good about it, I will tell you why in a bit).
The idea of using this tool is to help analyze the current vRA deployment and bring forth those areas which could potentially cause some problems once upgraded to vRA 7.3. The good part is that it helps us check automatically if the current setup is ready for the vRA 7.x upgrade.
It doesn’t carry around very stringent requirements to get the product started but for best results (or so to say, complete results) here are some of the recommendations:
Ideally you should run this tool on one of the IaaS Windows Server with the Model Manager Data. In a distributed deployment, take a look at the IaaS nodes and search for “C:\ProgramFiles\(x86)\VMware\vCAC\Server\Model Manager Data” folder. The Machine with this folder is the place where you run this Upgrade Assist Tool.
Once extracted, you should run the vRPT-1.6.0.exe executable , which should open up the EULA and take you straight into the page where you enter the details about the existing vRA deployment. It has some fairly straight-forward questions with respect to your vRA deployment such as the vRA portal name, the IaaS Web Host name, the vRO node name along with the respective credentials.
Note: In a distributed deployment, you are supposed to enter the Load Balanced IP/URL instead of the node name.
Now, the good part when compared with the earlier versions(of vRealize Production Test Tool), is that it allows you to test the connections before you run the tests. The Test Connection button prompts you if the credentials are correct, or you need to modify them.
Once green, you click on Save and Run, which would initiate the tests.
To make sure you are good with the .NET versions, disk space and other details, it is recommended to run this test on the additional IaaS machines to ensure you verify the pre-requisites for the upgrade.
It also has an additional option where you can send these test results to VMware, where it uploads the test output onto the VMware ftpsite. It is exactly the same way you upload the logs when you are working with VMware Technical Support.
To give you a sample of how the test output looks like, here it is:
The output would state if there are any vRO Workflows or physical endpoints which may not work post the upgrade to 7.x.
I would highly recommend to start the upgrade journey with the Upgrade Assist Tool and then move to the Checklists provided in the VMware Documentation at https://docs.vmware.com/en/vRealize-Automation/index.html
Oh yes, VMware Pubs has a cool new look. Check it out, if you haven’t.
Welcome 2017! Hope all is well with my readers. It has been a fabulous 2016 with great learnings.
Lately a lot of customers have reached out to me to help in planning their vSphere 6.0 setup(although 6.5 is already out and has awesome features which makes it a winner!).
These customers have a huge estate with a large number of vCenters and multiple ESXi Hosts. Either they are in a mode of consolidating them or re-designing them to have some sort of a CMA on top of it – That is a separate discussion altogether.
This has been my advice to most of my customers planning for the 6.0 setup. Hope this helps!
One of my customer was recently replacing the SSL Certificates on the Private Cloud environment based off version 6.2.3 of vRA. It was the first time they were doing this and hence he had done his research of going through the internet on various blogs on how to go about the replacement. So when he tried to lay down the steps based on the reading done on the internet, he was even more confused because the blogs differed by at least more than a step in the overall certificate replacement process. So thats when he involved me and I tried to look into it.
vRA(or I should say vCAC) 6.0 , 6.1 & in fact 6.2.0 were released quite some time back and hence we have a lot of blog posts which would talk with respect to those versions(of course 6.2 was not released then. Mind you a lot of blog posts do use the word vCAC 6, so it doesnt mean that ALL the steps are going to work for your 6.2.3 or 6.2.4 versions of vRA.
Then we decided that we fallback to the trusted pubs.vmware.com and it becomes really important to look into the version of documentation which we were looking into since there is a 6.0, 6.1 and a 6.2 documentation available.
Ok so first lesson learnt: Ensure whatever you are reading on the Internet is right and validate it with respect to the versions that you are working on.
In a nutshell if you ask me the process which we followed to get the certificates replaced came from http://pubs.vmware.com/vra-62/index.jsp#com.vmware.vra.install.doc/GUID-F493819D-D4FB-4854-BEC4-295388BB6EF7.html which clearly shows you the flow of your certificate changes. I am not going through each and every step as I said that the above VMware Documentation link tells you what exactly you are are supposed to do. I will try and fill in the other interesting details.
PRO TIP: Dont skip steps in the pubs and if you are referencing KB Articles, dont hop,skip and jump the lines in Knowledge Base Articles —-> Another lesson learnt!
As it mentions you start with the Identity Appliance and then you inform(or re-establish trust between the Identity Appliance & ) the vRA Appliance to let it know about the change in the Certificate on the Identity Appliance.
So in essence there are two parts to the whole certificate replacement:
- Replace the Actual Certificate using the Key and the Certificate itself
- Re-establishing Trust among the various other components.
You should update all the components of the same type in a distributed setup and then go for the trust re-establishment.
It is the Point#2 which caused a lot of confusion(prior to we reading the official VMware Documentation) . The confusion was due to the fact that the steps are different for 6.1 and 6.2 so take note of the versions involved.
For versions 6.2.x after replacing the certificates in the vRealize Automation Appliance and updating the SSO registration for the vRealize Automation Appliance, we update the IaaS Servers with the vRealize Automation Appliance Certificate(or to say re-establish the trust between the vRA appliances and the IaaS components) by running the command vcac-config.exe command from the the server running the Model Manager Data component using the UpdateServerCertificates argument
The command for 6.2.x would be “vcac-config UpdateServerCertificates –d <name of the vRA Database> -s <FQDN of the SQL Server hosting the vRA DB> -v” as compared to 6.1 where you use a “DownloadRootCertificates” argument with vcac-config.exe.
P.S: In vRA 6.2.3 you will not find the “DownloadRootCertificates” argument if you run the “vcac-config.exe help” command.
At this point, my attention was taken to a VMware KB Article http://kb.vmware.com/kb/2110207 which lists down the steps very clearly on how to re-establish the trust.
I would highly recommend you to read the KB article fully atleast twice, just to make sure you fully understand the sequence of steps because all of them are really important.
Since it is a distributed environment, you will have to run these commands on all the nodes of the same type & hence I would recommend(a wise guy told me to do this) that you copy down those commands on to a notepad and fill in those details as requested so that you could just copy and then paste in the Command Prompt of those IaaS Nodes.
P.S: you don’t need to run the last command in the step#11 with a Note which is specifically for 6.0 and NOT for 6.2.3.
Post the iisreset & reboot of the appliances and IaaS boxes. I again went back to our documentation at http://pubs.vmware.com/vra-62/index.jsp#com.vmware.vra.install.doc/GUID-F493819D-D4FB-4854-BEC4-295388BB6EF7.html to make sure I update the other certificates such as the VAMI for Identity and vRA Appliances.
Once done successfully, we are all set for another year with a clean set of SSL Certs across the board 🙂
I ran into a couple of other issues such as creating the certificate chain, so it is important that you create the certificate chain in the right order which is:
- Server Certificate signed by the Intermediate CA
- Intermediate Certificate
- Root Certificate.
Although this is mentioned clearly in our documentation, we missed out on this too, so I wanted to make sure you guys don’t miss this.
Hope this helps!
Recently I was working with one of the customer who was migrating his SAP environment from IBM AIX to Cisco’s UCS platform and the customer was looking for some Best Practices from a VMware standpoint. I thought, this would make a good blog post.
There’s lot of information out there, but the following should help you get started.
So here they are:
- The basis team should leverage Early Watch Reports to come up with sizing for the SAP virtual machines. Use requirements from the basis team for the application and DB servers for all the modules. The sizing should be done based on their existing environment and its utilization.
- Follow SAPS based workload Sizing recommendations.
- Reserved all memory based on SAP best practices for production. Definitely no overcommitment of Memory.
- Size VMs so that CPU and memory will fit within NUMA boundaries.
- Reserve Memory for SAP Production Virtual Machines.
- Ensure database servers separate LUNS for data , logs, and archive.
- The Guest OS swap will be separated to a LUN that is not replicated.
- The boot disk and all other disk partitions should be aligned for optimal performance at the VMFS and the OS level.
- Leverage Cisco UCS service profile to create consistent server Hardware configurations.
- Plan vCPU per CPU core based on applications requirements. HT should be enabled to reduce impact of over commitment.
- The ESX hosts for the SAP environment needs to exist in a dedicated cluster with its own networking and storage zoning.
- Ensure virtual machines are configured to fit within NUMA nodes.
- Host profiles should be leveraged to ensure consistent configuration across all ESX hosts in the cluster.
- Database Storage Design should be similar to Physical. We also need to factor in space to be used by the .vswp files in the Virtual Machines. The size of a .vswp file is equal to Total configured memory – reservation if provided. So if no reservations are provided, then the size of each .vswp file is equal to the amount of memory and hence the Storage sizing needs to factor that as well for the overall sizing.
- Use separate LUNs for OS,Data and Swap.
- Dedicate LUNs provided for DB related files to guarantee the required performance.
- All Database and Application disks should be Eager-Zero Thick Provisioned.
- Guest Page Files should be stored in a separate disks.
- At the Storage level, use Thick Provisioning.
- Use the UCS capability to create vNICs for separate ports for management,vMotion and Production traffic. Separate them by VLANs.
- The standard SAP Rules apply for Databases. See SAP Note 592393.
- See SAP Note 1056052 for additional vSphere Guidelines – https://service.sap.com/sap/support/notes/1056052
Few good online resources:
Also note there was a recent announcement at SAPHIRE 2016, few days back(17th May) that SAP supports SAP HANA on vSphere 6 . Please see http://blogs.vmware.com/apps/2016/05/sap-hana-on-vsphere-deployment-options-and-best-practices.html
Holla! It’s been some time that I wrote on my blog, I am happy to share my recent experience with one of the customer who runs a private cloud built out of the vCloud Suite.
The customer is running a 6.2 vRealize Automation built on top of vCenter Server 5.5 U2d and ESXi 5.5U2. The R&D Team immediately needed a couple of CentOS7 machines to run their builds, however the current catalog did not have it.
The Cloud Infrastructure and Management team curated a CentOS7 machine and built it as per their organizational standards and had VMware Tools installed, created a template and finally got that added as a catalog item on the vRA Catalog list.
Here comes the situation: VMs provisioned by the vRA portal were being allocated IP Addresses from the Network Profiles, however when we logged into those CentOS7 machines, we did not see any IPv4 assigned to it(it showed a IPv6). Neither did we see the IP Address on the Summary page of the VM on the vSphere Web Client/vSphere Client.
We were already running CentOS6.6/RHEL6/RHEL7 as catalog items and they were just running perfectly fine! What could be wrong with CentOS7? After all we were using the same Customization Specification for all Linux based machines!!
Ok. So lets do a recap – vRA provisioned the machine, it allocated an IP from the Network Profile, it also initiated a Customize Machine workflow to get it customized and it was powered on. We verified this by looking at the Tasks and Events of that machine as well, all of them were Completed successfully.
The customization tasks showed us a line stating that “For details, reference the log file /var/log/vmware-imc/toolsDeployPkg.log in the guest OS”
We looked into the file and we see that the IP Address field was blank in the toolsDeploypkg.log file which hinted us that probably there is something wrong with the Guest Customization Specification. But hey, how come we were able to successfully provision other VMs out of the same spec!
This made us turn to our favourite messiah – Google!! and we stumbled upon https://lonesysadmin.net/2015/01/06/centos-7-refusing-vmware-vsphere-guest-os-customizations/ by @plankers .
The trick was to fool the customization spec to believe that /etc/redhat-release stated “Red Hat Enterprise Linux Server release 7.0 (Maipo)”
Once this was done, the trick worked!!!
Only after this we saw this really important document – Guest OS Customization Support Matrix at http://partnerweb.vmware.com/programs/guestOS/guest-os-customization-matrix.pdf which stated the obvious – CentOS7 requires vCenter Server to be at the 5.5 Update 3 Build, which we were not.
The above is a hack(definitely not supported by VMware Support), I would highly recommend you to get the Upgrade done.
However in my customer’s case, where the Upgrade had a lot of dependencies, this was a quick and dirty way to get CentOS7 machines to the R&D folks, which made them happy!!
Thanks to @plankers.
- Pre-requisites – Check compatibility guides, in this case the GOS Customization Support Matrix.
- Search better in Google! 😉