Maintenance mode esxi что это
You are using an outdated browser. Please upgrade your browser to improve your experience.
You place a host in maintenance mode when you need to service it, for example, to install more memory. A host enters or leaves maintenance mode only as the result of a user request.
Virtual machines that are running on a host entering maintenance mode need to be migrated to another host (either manually or automatically by DRS) or shut down. The host is in a state of Entering Maintenance Mode until all running virtual machines are powered down or migrated to different hosts. You cannot power on virtual machines or migrate virtual machines to a host entering maintenance mode.
When no more running virtual machines are on the host, the host’s icon changes to include under maintenance and the host’s Summary panel indicates the new state. While in maintenance mode, the host does not allow you to deploy or power on a virtual machine.
Procedure
- Browse to the host in the vSphere Client .
- Right-click the host and select Maintenance Mode > Enter Maintenance Mode .
- If the host is part of a partially automated or manual DRS cluster, browse to Cluster > Monitor > DRS > Recommendations and click Apply Recommendations .
- If the host is part of an automated DRS cluster, virtual machines are migrated to different hosts when the host enters maintenance mode.
Results
The host is in maintenance mode until you select Maintenance Mode > Exit Maintenance Mode .
Maintenance mode esxi что это
Some installation and update operations that use live install require the host to be in maintenance mode.
Maintenance mode is required when an update operation requires a reboot. However, you only put the host in maintenance mode manually when you use esxcli commands for update and upgrade operations.
To determine whether an upgrade operation requires the host to be in maintenance mode, see Determine Whether an Update Requires a Host to Be in Maintenance Mode or to Be Rebooted
When you specify a target server by using —server=< server_name > , the server prompts you for a user name and password. Other connection options, such as a configuration file or session file, are supported. For a list of connection options, see Getting Started with ESXCLI, or run esxcli —help at the ESXCLI command prompt.
Prerequisites
Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the ESXi Shell .
Procedure
- Check whether the host is in maintenance mode.
| Option | Command |
|---|---|
| To shut down the guest operating system and then power off the virtual machine | |
| To power off the virtual machine immediately | |
| To force the power off operation |
Alternatively, to avoid powering off virtual machines, you can migrate them to another host. See the topic Migrating Virtual Machines in the vCenter Server and Host Management documentation.
ESXi Maintenance Mode Via CLI How-to And Some More Commands
A short post to bookmark some CLI commands for putting a VMware ESXi host into a maintenance mode. In my lab, I’m running vCenter in a VM, and this VM runs out of a small local datastore. So I can’t simply vMotion this VM elsewhere to do a maintenance and patch using VMware Update Manager (VUM).
When the host where that VM runs, needs to be put into maintenance mode, one needs the CLI. That’s why this post. But while here I’ll add some more commands which are useful for rebooting, or checking up the VMs that runs on the host etc… which might be useful too.
ESXi maintenance mode is mode when it’s possible to install patches and updates or plan for a hardware upgrade such as adding more RAM or more internal hard drives. You might also need to service your host to install new firmware to your storage controller, to your motherboard etc. So the use cases for using a maintenance mode are numerous.
The host is in a state of Entering Maintenance Mode until all running virtual machines are suspended or migrated. When a host is entering maintenance mode, you cannot power on virtual machines on it or migrate virtual machines to it.
Whether you patching standalone ESXi host or if you’re using VMware Update manager for patching, in both cases you must put a host into maintenance mode. In case you’re using VUM the host is placed into maintenance mode automatically.
If you have VMs running on the host, you must migrate them or shut them down. You cannot leave VM running and put a host into a maintenance mode as the system will wait until all running VMs are shut down or are migrated elsewhere.
How to put a host into maintenance mode?
To enter maintenance mode using the command line interface, use this command:
esxcli system maintenanceMode set –enable true
To exit maintenance mode use this command:
esxcli system maintenanceMode set –enable false
Alternatively, there is another command to enter and to exit maintenance mode:
To enter maintenance mode:
To exit maintenance mode:
vimsh -n -e /hostsvc/maintenance_mode_exit
To check if the host is in maintenance mode:
Use one of these commands:
vim-cmd /hostsvc/hostsummary | grep inMaintenanceMode
vimsh -n -e /hostsvc/hostsummary | grep inMaintenanceMode
While here, some quick commands how to reboot, halt or shutdown:
Through the vMA (vSphere Management Appliance):
From the vMA command prompt, you can also enter maintenance mode.
vicfg-hostops -o enter –server 10.10.5.10
To exit maintenance mode from vMA enter the following.
vicfg-hostops -o exit –server 10.10.5.10
You can also shutdown or reboot ESXi hosts command from vMA.
vicfg-hostops -o shutdown –server 10.10.5.10
vicfg-hostops -o reboot –server 10.10.5.10
Find out which VMs are running on ESXi host:
Check out also my post on How-to power off unresponsive VM through the CLI.
Links:
Wrap Up:
Maintenance mode is a special state where the system assures that no VMs are running so the patching/upgrade of the host is possible. After the host has entered the Maintenance mode, no VMs can be deployed or powered-on on the host.
When no more running virtual machines are on the host, the host’s icon changes to include under maintenance and the host’s Summary panel indicates the new state. Host can exit the maintenance mode automatically after the patching process has finished and rebooted the host only if managed via vSphere Update Manager (VUM). If it is an individual host, no automatic maintenance mode exists.
VMware Update Manager is now part of VMware vCenter Server Appliance (VCSA). Windows-based vCenter needs a separate DB and separate software component. VMware is phasing out the Windows vCenter. The latest news was that the next release of VMware vSphere will be the last release where the Windows vCenter server will be part of the vSphere suite.
Back to Basics – vSphere Maintenance Mode
I’ve noticed over the years that while VMware admins tend to really understand maintenance mode, a lot of others in adjacent spaces (storage, network, etc.) have a very murky perspective on it. In fact, I’d bet that if you sat down a storage person at vCenter and told them to evacuate a host with MM, odds are they would be really confused when the task hung or failed. I know I was the first time I tried it.
In case you don’t know, maintenance mode is an option for a host that is designed to non-disruptively clear off any running VMs via vMotion (and possibly powered down/suspended VMs) in order for “something” to be done to that host. A lot of times this is just a reboot. Most of our lives (“us” being storage guys) are spent directing other people to do this. “Just put it in maintenance mode,” we tell the VMware admin. We know implicitly that this is going to vMotion all the guests off of it automagically. But really this isn’t always true. Actually it is only true in one case.
Maintenance mode is always an option for a host, regardless of whether the cluster has DRS enabled or what mode it is in. But the behavior of MM is contingent on the DRS settings for the cluster.
When enabled, DRS has three different modes of operation. Briefly those are:
- Manual – This option generates DRS recommendations that the VMware admin can apply, but it does not automatically move or place VMs
- Partially Automated – This option also generates DRS recommendations, and also does not automatically move VMs. However it does attempt to balance the cluster by placing VMs on specific hosts when those guests are powered on.
- Fully Automated – This option automatically places VMs at power on, as well as actively moves VMs to balance the cluster load. There is an additional slider that controls how conservatively (infrequent) or aggressively (frequent) the moves happen.
So you have a cluster with DRS enabled in partially automated mode and you go to maintenance mode a host, and it just sits and spins. Eventually the task times out and fails. Why?
This is because maintenance mode actually generates DRS move recommendations, and in partially automated mode (as well as manual mode) DRS won’t automatically apply move recommendations. The host is waiting for you to either manually relocate VMs or apply the generated recommendations. Here I’ve put a host in MM in a Manual mode cluster, and you can see the DRS recommendations available.
But those recommendations will just sit there until applied, and the host will sit waiting to enter maintenance mode until you either apply those recommendations or you manually migrate with vMotion.
One good thing about the DRS recommendations is that there isn’t really a need to disable or tweak DRS when entering MM, even in fully automated mode. Think about it – if DRS is responsible for ensuring balanced load across all hosts, then as a host was evacuating VMs for MM it would say “hey, there is a free host with nothing on it, we should load that up!” It would be moving stuff on while MM was moving stuff off. But because DRS is MM aware we don’t have to worry about that.
Another nice thing about MM is that it won’t complete until the VMs are migrated off. So say you didn’t know about all these details around MM not being fully automated in certain clusters. It isn’t going to actually put the host into MM while there are still running VMs on it, causing an outage. The MM task will simply time out and fail.
So we have four DRS options for a given cluster. Here are how they break down with MM:
- DRS Disabled – in this case a host will start to enter maintenance mode, but will not complete until all VMs are evacuated. Because DRS is disabled, an administrator is required to manually migrate all VMs to other hosts with vMotion.
- DRS Enabled, Manual or Partially Automated – Similar to DRS disabled, the host will start to enter but won’t complete until all VMs are evacuated. Manual migration via vMotion is still an option but an easier way is to go to the DRS recommendations page which should have recommendations to evacuate all guests because the host is entering MM. Then you can just apply the recommendations.
- DRS Enabled, Fully Automated – This mode will automatically evacuate the host with no administrator intervention required.
Here are some other things to keep in mind.
First, HA should have no meaningful interaction with maintenance mode because there should be no outage (guest or host) during the process. There is a maintenance option with HA, seen here.
This is intended for anyone doing network maintenance on the management network. Essentially if the management network goes down but the guest networks are up, we don’t want a full cluster freak out. But again, no need to monkey with this if you are just doing maintenance mode.
Second, aside from random reboots vSphere Update Manager is going to be a big source of MM as well. If you are applying new VIBs or patching, it is likely going to need to put hosts in MM, and it will follow the same rules as regular MM (behavior is based on DRS settings). This is really important to note if you have scheduled patch updates which you expect to complete automatically after hours! If your DRS cluster is in anything other than Fully Automated, you will require administrator intervention to complete the process.
Next, don’t forget about any VM Overrides with respect to the DRS settings. Sometimes in fully automated clusters, you may have VM Overrides set for VMs that you don’t want moving during the day, like VOIP related servers. If a VM Override sets a VM to Partially Automated or Manual, that will also require administrator intervention.
Finally, the conservative/aggressive setting. Because MM is tied into DRS and generates DRS recommendations there isn’t really an issue no matter where this slider is. However for the paranoid with fully automated DRS, you can adjust the slider to the most conservative setting which will essentially stop generating DRS moves based on load balancing but still honor moves for MM and affinity settings.
An interesting question here is, what if I have anti-affinity rules that would be violated by the MM setting? An easy enough thing to check as I only have two hosts in my lab. I created an anti-affinity rule for two VMs:
With my cluster in Partially Automated mode and the VMs distributed on separate hosts, I tried to put one host into MM and then checked the DRS recommendations.
Notice that while there are two recommended moves here, there is not a move for linuxdns which is also on that host. This is because that move would violate the anti-affinity rule I put in place. So I have to manually migrate that VM with vMotion.
Also kind of interesting is that the vMotion compatibility checker will also recognize that a host is going into MM and not let you vMotion to it.
After the vMotion completes, the host goes into MM like normal. Same thing if the cluster is in Fully Automated mode as well.
So in summary, when using MM make sure to keep the cluster DRS settings, as well as any VM overrides and affinity/anti-affinity rules, in mind so that your MM and updates aren’t impacted. It is likely that with a larger cluster, anti-affinity rules can still be satisfied even with hosts going into MM, but remember that there are also different kinds of affinity rules as well as VUM having the ability to execute some patching in parallel if you have enough resources in your cluster…so multiple hosts may be going into MM at the same time. There are a lot of different configuration options but hopefully this post will help clear up the behavior for you.