VMworld 2017: AppDefense Aims to Flip the Current Security Model on Its Head
The company’s new tool uses the power of virtualization to protect apps and data.
migrate2vcsa – Migrating vCenter 6.0 to 6.5 VCSA
Over the past few years i’ve written a couple of articles on upgrading vCenter from 5.5 to 6.0. Firstly an in place upgrade of the 5.5 VCSA to 6.0 and then more recently an in place upgrade of a Windows 5.5 vCenter to 6.0. This week I upgraded and migrated my NestedESXi SliemaLab vCenter using the migrate2vcsa tool that’s now The post migrate2vcsa – Migrating vCenter 6.0 to 6.5 VSCA appeared first on VIRTUALIZATION IS LIFE! .
Released: vCenter and ESXi 6.0 Update 3 – What’s in It for Service Providers — via VIRTUALIZATION IS LIFE!
Last month I wrote a blog post on upgrading vCenter 5.5 to 6.0 Update 2 and during the course of writing that blog post I conducted a survey on which version of vSphere most people where seeing out in the wild…overwhelmingly vSphere 6.0 was the most popular version with 5.5 second and 6.5 lagging in adoption for the moment.
New vCenter Server Appliance Deployment Walkthroughs – via VMware vSphere Blog
vSphere 6.5 takes the VCSA deployment experience to the next level. The VCSA 6.5 installer no longer requires a plugin, making it browser agnostic. If that wasn’t enough, the VCSA installer now supports use on macOS, Linux, and Window. The VMware Feature Walkthrough site has two new VCSA 6.5 deployment walkthroughs. These two step-by-step guides cover the VCSA 6.5 embedded and external deployments.
New vCenter Server Appliance File-Based Backup / Restore Walkthroughs
The vCenter Server Appliance (VCSA) 6.5 is full of new and exclusive features. One of which is the native file-based backup and restore. I’m happy to announce two new guided walkthroughs on the VMware Feature Walkthrough site.
Let’s go over how to disable the “This host currently has no management network redundancy” message. It’s annoying and we can get rid of the yellow triangles that show on the hosts due to this message. And I know, you “should” have redundancy on your management network but we’re just not worried about it. Our hosts are in our building and not at a co-lo so we have constant access to them in the event something happens and we need access.
Since we don’t care about this warning, I wanted to hide it. This way we can see if there are actual errors on the host and not some warning about network redundancy. The fix is done with an advanced option in the cluster properties. In the cluster properties, under vSphere HA, select Advanced Options. Then add an option named das.ignoreRedundantNetWarning and set the Value to true.
Today when logging into the vSphere Web Client to document the SRM testing process, I noticed that the SRM plugin did not show on the home screen. However, when logging into the protected site I noticed that it was there. Here are my troubleshooting steps:
1. Logged into the SRM server and noticed the service was not running. I started the service and tried logging into the web client, but the plugin was still not showing.
2. I then rebooted the SRM box and logged back into the web client. Still no plugin.
3. I restarted the vCenter service and web managementservices on the vCenter box. Still no plugin.
4. Finally, I restarted the web client service on the vcenter box. Logged into the web client, and voila! Plugin was showing.
The root cause is that the SRM service must be running. If it is not, start the service and then restart the web client service on the vCenter server.
I had to redeploy a vCenter Server Appliance recently and got an error when opening vCenter: sysimage.fault.SSLCertificateError.
This is caused by the certificate on the vCenter Server changing. This causes the Upgrade Manager needing to be re-registered with the vCenter Server. Luckily, VMware provides a utility to do just that. Go to your vCenter Upgrade Manager Server (The appliance does not include this, so it will typically be installed on a separate Windows Server).
Go to “C:\Program Files (x86)\VMware\Infrastructure\Update Manager” and open the file “VMwareUpdateManagerUtility”.
I recently had an issue where I was unable to remove a datastore from the vCenter Server Inventory. The datastore was grayed out and when right-clicking, had no options. After some digging and some research in SQL, I found a way to manually do this in the vCenter database. Every datastore is given a unique ID and can be found and removed inside of the database.
Warning: Always make a SQL backup before attempting any manual database changes. You never know when things might break and you need to restore.
So here we go:
select ID from VPX_ENTITY where name = ‘datastore_name’
delete from VPX_DS_ASSIGNMENT where DS_ID=ID;
delete from VPX_VM_DS_SPACE where DS_ID=ID;
delete from VPX_DATASTORE where ID=ID;
delete from VPX_ENTITY where ID=ID;
If you want to verify that everything went correctly, you can run the following:select * from VPX_DS_ASSIGNMENT where DS_ID=ID; select * from VPX_VM_DS_SPACE where DS_ID=ID; select * from VPX_DATASTORE where ID=ID; select * from VPX_ENTITY where ID=ID;
Now you’ve removed the datastore from the database and can start the vCenter Server Service again. If you don’t see that it has been removed, a reboot may help. I rebooted my server just to be on the safe side.
You can check out this VMware KB for more info.
A recent issue we experienced was seeing hosts disconnecting from vCenter and reconnecting. The host would drop and randomly come back for about an hour or more. The VM’s never saw any issues nor was there any type of outage. It was that vCenter could no longer see the host.
After quite a bit of troubleshooting, I started digging around in the vCenter Server Settings (Administration > vCenter Server Settings). In this menu, there is a tab for Runtime settings. I noticed that we only had the vCenter Server Name filled in and not the vCenter Server Managed IP. The window looks as follows:
After completing all the fields in this window, the hosts magically all reconnected and have not dropped again. This is due to the fact that the hosts use these settings to check in with the vCenter box and they let the host know who it’s being managed by. As you can guess, if the host doesn’t know who’s managing it, it doesn’t know who to check in with.
The more curious issue was that this field hadn’t even been filled out, but didn’t start immediately. Which made troubleshooting more difficult and made us all panic as we started getting numerous alerts for hosts dropping.
As best practice, whether you only have 1 vCenter server, is to fill out all these fields and enure they are correct. Especially if you want the host to check in with the correct vCenter server and you don’t want the heart attack of seeing numerous hosts suddenly disconnecting from vCenter.