Recently, we need to use a feature in vROPS 6.2+ to dump alerts into a folder. One of the outbound settings in vROPS is “Log File Plugin”. When you configure it, you tell vROPS to create a text file for each alert in an output folder in the appliance. The recommendation from VMware is that this output folder should be an mounted volume pointing to an external source so that you don’t eat up all the disk space in the appliance. Read the rest of this entry »
Tag Archives: vmware
Updated this article after Peter’s comments and my own testing
During failover of an RP4VM consistency group (CG), you have a few choices of selecting the test network to failover your VMs in. Why is this necessary?
A totally interesting read on how the team in VMware resolved an issue with a non performing HP blade. The final take away from this is:
- Thermal paste really can impact performance!
- HP Active Health System logs should (but don’t) include when CPU’s clock down to prevent overheating.
- CPU clock throttled error message don’t appear in ESXi logs.
For the longest time VMware administrators have been using the C# VSphere clients or “fat client”. Over the years, it continues to plague us with hidden confirmation dialog boxes, error dialog boxes that pop-up continuously, version incompatibilities on the same computer and application crashes.
Worst of all are the need to test, package and supply new versions of the client whenever the infrastructure is upgrade. Its not a big deal if the only persons to use it are your own VMware administrators. But in big organisation with VDI in the mix, you need to hand off new versions to desktop support and even end users themselves. Worst of all, is the need for a clean uninstall of the older versions before the new versions can be installed or else you may end up with knackered computer which won’t run either versions. Read the rest of this entry »
Good news to some folks is that vCenter Server Appliance 6.0 is now on par with its former enterprise siblings, namely, vCenter on Windows + SQL or vCSA with Oracle.
For big enterprises, it is very common to install vCenter into a Windows machine and setting up the databases with your DBA admins on SQL. One of the main problem with this is the process of getting a database or expanding databases when you run of out of space. It can take time to setup a new vCenter or you often end up expanding the databases with an incident ticket. The other problem is that because the SQL database is managed by the DBA team, you are dependent on that team’s effectiveness to keep your vCenter running. There are times within busy periods of a DBA teams where you might find the vCenter service stopping or failing due to a stuck job or running out of space on SQL but your team was not alerted in time causing an incident.
Thus running your own vCSA, if you have a big enough cloud team, is probably a better solution in keep the lights up for your vCenter server, especially if they are consumed by VDI/Desktop teams and workflow applications like Orchestrator.
Of course, the challenge for Windows folks like me is having to master a new Linux OS and vPostgres database for optimization and troubleshooting. But these are alwasy good challenges to have.
I guess most of us have had the experience of getting an ESXi host into maintenance mode and finding that it got stuck with one last VM. When you look into host, you also see shutdown VMs and templates still hosted by this ESXi and you have to manually move them out before trying to get that last VM fixed so that you can get into the maintenance mode.
Great news with the vSphere 6.0 Update 2, now the order of evacuation for host going into maintenance mode is improved! Specifically:
Starting with vSphere 6.0 Update 2, when a host enters Maintenance Mode the host will evacuate all the powered off VMs and templates first, and then proceed to vMotion all the powered on VMs.
For many who have moved on to vSphere 5.1 and beyond, and despite VMware’s focus on web-based management instead of the fat client, we still had to use the fat client to connect to and managed ESXi hosts. Great news as now there is a web based client to manage ESXi host directly. You do have have to install a VIB to your host for this to happen (I am sure this will be integrated in later versions) and it only works on 5.5 U3 and above, which will be released later.