There are multiple ways available to patch a VMware Infrastructure. Two of the very common ones are through Update Manager or esxcli.
Update Manager enables centralized, automated patch and version management for VMware vSphere and offers support for VMware ESXi hosts, and virtual machines. Unfortunately it is available only on vCenter deployments and you cannot use it on standalone hosts.
When you need to update a standalone host you can follow the procedure described below.
In my case I wanted to patch an ESXi host from 6.7 Build 8941472 to 6.7 Build 9484548.
First you download the patch definitions from VMware site. In my case I needed to download the below bundle package:
Then, the package should be uploaded to the local or any available datastore so that host can access it. Also ssh should be enabled so that one can connect on the host with root account.
file upload can be performed from the available esx host GUI
change directory and find the location of the file
Lastly execute the below command, and reboot the host
esxcli software vib update --depot filePath
The version available after the reboot, should be the new one
Ansible is a very powerful automation tool that is developed from RedHat. Many large organizations rely on Ansible to automate tasks and procedures. In this article I will explain how one can use ansible to manage windows clients and servers.
In order to manage windows hosts ansible winrm plugin should be used to communicate with the client/server machine.
The first step is to verify that ansible is installed.
Alongside with ansible, on the control node the pywinrm module should be also installed. By default this one is not installed and one should do it manually.
The managed Windows client/server machines should be configured to allow remote connections. A very useful power shell script is already developed from other users and it needs only to be executed on the managed host.
If your execution policy is prohibiting this script to be executed, you should set-execution policy to RemoteSigned as shown below and then execute the powershell.
Control node should have network connectivity with the managed hosts.
Some environmental variables should be used, so that ansible knows how the connection will be performed (winrm). I included those variables in my inventory file as I created this lab just for demonstration. My inventory file looks like below:
Lastly make sure that the user that is used for the connection has administrative rights on the managed windows hosts. Otherwise some error codes will be returned.
Lastly confirm ansible on managed host is working by using win_ping module.
Availability is a critical matter when it refers to systems. The ideal scenario for an administrator would be 100% availability for a virtual server/appliance.
However this is not achievable when we deal with infrastructure as we need to close the systems on purpose (patching, maintenance tasks, etc) but also disasters or other nonphysical causes create a downtime.
When we deal with Azure cloud we have the following options that we can use:
Availability sets
Availability zone
An Availability Zone is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. To ensure resiliency, there’s a minimum of three separate zones in all enabled regions
Availability sets are another datacenter configuration to provide VM redundancy and availability. This configuration within a datacenter ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available and meets the 99.95% Azure SLA. For more information, see the SLA for Virtual Machines.
When you create a new VM resource on Azure, you should choose between availability sets or availability zone (depending on the region on which you deployed your server)
However as stated in the first article from Microsoft:
To achieve comprehensive business continuity on Azure, build your application architecture using the combination of Availability Zones with Azure region pairs. You can synchronously replicate your applications and data using Availability Zones within an Azure region for high-availability and asynchronously replicate across Azure regions for disaster recovery protection.
So the final image is the below. Based on your needs you could choose whichever option is more appropriate for you. However as recommended from Microsoft, you should use availability zones (newer feature than availability sets)
Below are some very good resources that Microsoft provides:
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy