Updated based on feedback. Thanks for the comments!
I’d like to revisit the question “are ESXi patches cumulative”? This time I hope to hammer home the point with an example.
In short, the answer is yes, the ESXi patch bundles are cumulative. However, when applying patches from the command line using the ESXCLI command you do need to be careful to ensure you update the complete image profile and not just select VIBs.
There are two ways to update VIBs using the ESCLI command. You can use either the “esxcli software vib update …“ command or the “esxcli software profile update …” command. The “vib” namespace is typically used with the optional “-n <vib name>” parameter in order to update individual VIBs, where the “profile” namespace is typically used to update the host’s image profile, which may include multiple VIB updates. The key is when applying patches use the “profile” namespace to update the complete image profile opposed to using the “vib” namespace to update selected VIBs.
On August 26th at VMworld 2013 VMware announced vSphere 5.5, the latest release of VMware’s industry-leading virtualization platform. This latest release includes a lot of improvements and many new features and capabilities. In an effort to try and get my head around all this exciting new “stuff” I decided to go through the what’s new paper and compile a brief summary (well, relatively brief anyway).
Here’s the list I came up with. I’m sure I missed some things, but this list should help you get started with learning about what’s new in vSphere 5.5.
Recently I installed vCenter Log Insight, which by the way has one of the easiest and intuitive installers and configuration wizards ever!
After the Install and during the configuration you can easily add your vCenter server and vCOPs server so that monitoring can start straight away.
As an extra configuration step you can extend the default logging by setting up each ESXi host to use the Syslog server which is built into Log Insight, the process for this can be found in the documentation located here.
As per the documentation this means either going to each host and configuring the Syslog settings, configuring them manually through the shell or running the configure-esxi script through an SSH session.
As I already had a PowerCLI session open to my environment I wrote a quick PowerCLI script to achieve the same thing, the following script will configure the Syslog settings for each ESXi host to send their events to Log Insight…..
If you are an experienced vSphere admin then this post may not be for you. However, if you are new or just getting started on your journey to virtualization and vSphere with Operations Management (VSOM) then please keep reading…
I was once asked: “Explain how a brand new admin who wanted to install vSphere with Operations Management (VSOM) for the first time would go about doing that?”. While my initial thought was “Ah, that’s easy!”, in trying to answer this question it occurred to me that it’s actually quite involved, especially when you are new. You would need to do some research to understand the components, in the course of this research you would come across many new terms and acronyms and several different installation guides. Bottom line, a lot of time would be spent trying to figure out what the pieces are and how they fit together, and this is all before you install the first component.
This got me thinking about the challenges new IT professionals face and how it can be difficult having to sift through the vast amount of data trying to get answers to even the simple questions.
It’s in this spirit that we have created a new video series entitled “Getting Started – vSphere with Operations Management”. These videos are aimed specifically at helping new IT professionals get started with VSOM. The series starts by introducing you to the principals of virtualization and then guide you through the process of installing and configuring each VSOM component. The aim is to to help you spend less time researching and more time doing. These videos are basic, the goal was simple – to provide a series of introductory videos targeted at people who are new to vSphere in order to help get them through the initial learning curve. Continue reading →
Is there a good reason you don’t use VMware Auto Deploy?
Here at VMware we value our customers feedback and want to help make sure our product lines and features are in line with what is needed from your organization, as part of this we are trying to find out more details about how our customers use Auto Deploy, or if you don’t , how they don’t use Auto Deploy!
As part of this we have created a survey which will help prioritize efforts in the future and give us a clearer picture on how customers are or are not using Auto Deploy.
The survey takes you to different pages based upon your answers so please do not get scared by the number of pages at the top, this will quickly reduce and should take less than 5 minutes to complete.
As a thank you for filling this survey out, at the end you will have the chance to add your email address (optional) and be entered into a draw to receive 1 of 3 copies of VMware fusion, winners will be contacted after the end of the survey.
Thanks for taking the time to help make VMware products better.
A few weeks ago I saw on an internal email thread an ask from a customer via their VMware sale engineer. The customer was using AutoDeploy and Host Profiles. As part of this process, they were creating a local user on their ESXi hosts and when they connected to the host via the vSphere Client application on Windows, they were worried to see that the user was created with Shell Access already granted! As you can imagine, that’s probably not something you want done by default. Even more so when you’re in an environment that has compliance concerns. And especially when you have the Security Guy looking over your shoulder!
Well, like our friends from Down Under would say, “No Worries Mate”. What you are seeing here is a UI bug in the vSphere Windows Client. As you know, the vSphere Windows Client has been superseded by the new vSphere Web Client. But at the moment, it’s the main tool for configuration by those who connect to ESXi servers. With the vSphere Web Client being the current and future client user interface for vCenter Server managed objects and resources, the “old” vSphere Client may, at times, not be as current as we’d like.
vSphere 5.1 Update 1 was just released last week and one of the things that caught my eye while reading through the release notes for ESXi 5.1 Update 1 was a new enhancement to hostd logging:
Component-based logging and advanced configurations added to hostd log level
To avoid difficulties in getting appropriate logs during an issue, this release introduces component-based logging by dividing the loggers into different groups and prefixing them. Also, new advanced configuration allows you to change hostd log’s log level without restarting.
Though this enhancement is targeted for troubleshooting purposes and will most likely be used when working with GSS. I thought I would walk you through on how this feature works as there were not much detail in the release notes.
Patch management for ESXi is very different compared to traditional operating system patches, where incremental updates are made to the base operating system and thus increasing the disk footprint for each patch update. For the ESXi hypervisor, when a patch is applied, the entire ESXi image also known as an Image Profile is replaced. This means that each time you patch or upgrade your ESXi host, you are not adding on top of the original installation size.
The Auto Deploy server has two components: the rules engine and the web server.
(1) Rules engine: parses the host attributes to identify the image profile, host profile, and vCenter location (cluster or folder). The rules are created ahead of time by the administrator using PowerCLI.
(2) Web server: copies the ESXi image profile to the host along with a copy of the host profile definition that will be used to configure the host after it connects to the vCenter server.
If your going to be in Las Vegas for the annual 2013 VMware Partner Exchange, why don’t you come and check out my sessions on vSphere 5.1 covering the vSphere web client and vCenter components like Single Sign-On
Thursday, Feb 28, 9:00 AM – 10:00 AM CI1544 - vSphere Web Client - Technical Walkthrough With the release of vSphere 5.1 was a new primary client for the management of vSphere Solutions. With this session we will build competency in the adoption of the vSphere Web Client by highlighting the differences, easing the initial reaction to a Web Client and show you how to wow your customers with real world use cases
Thursday, Feb 28, 10:15 AM – 12:15 PM CI1545 - vSphere – Deployment Best Practices With the new technologies introduced with vSphere 5.1 many unanswered questions exist with designing and deploying the vSphere 5.1 environment. This session will share best practices learned from the field and provide common scenarios with recommended configurations of vCenter, Single Sign-On, Inventory Service and the web client that will future proof your customers environment. This session has now been extended to include Kyle Gleed (@VMwareESXi) discussing best practices on deploying and working with vSphere hosts (ESXi)