VMware Cloud Community
StephenMoll
Expert
Expert

Enter Maintenance Mode from vCenter vs. from ESXi

If I use the Web Client to put one of a cluster's hosts into maintenance mode, running VMs will be nicely migrated away and then the host goes into maintenance mode.

If I use the Web GUI to ESXi to put the same host into maintenance mode, vCenter does nothing and the task times out and fails.

Is it possible for vCenter to do carry out the same assistance when a maintenance mode is triggered locally at a host?

0 Kudos
9 Replies
RajeevVCP4
Expert
Expert

you mean to say logging by root on single host ? if yes you can not put single host on m-mode

Rajeev Chauhan
VCIX-DCV6.5/VSAN/VXRAIL
Please mark help full or correct if my answer is use full for you
0 Kudos
StephenMoll
Expert
Expert

Sorry, I beg to differ.

If I log into ESXi web GUI and initiate "Enter Maintenance Mode", it will warn me that VMs have to be moved or shutdown. If I do that manually, then the task to enter maintenance mode successfully completes and vCenter updates to show the host in maintenance mode. So directly logging into a host and putting it into maintenance mode can work. I thought it was clear from my initial post I am talking about a cluster of hosts.

The only bit that is missing is vCenter detecting maintenance mode entry task being triggered at the host and behaving in the same way as if the task was initiated in vCenter.

0 Kudos
sjesse
Leadership
Leadership

I don't think the esxi host gui is designed that way, from the esxi host gui its only away of its self, not any other host. There would need to be a more comprehensive two way communication that I don't think there is right now, vcenter mostly just logs in and checks on the status, and if I remember right its not Realtime. I never really try to do anything in the host directly if vcenter is available.

0 Kudos
StephenMoll
Expert
Expert

That is the view I have, but thought I would ask anyway.

The activity is around the development of a management function to deal with automated shutdown triggered by UPS on battery events. The nature of the network and infrastructure means that we cannot rely on VCSA being contactable, and the time constraints mean that it would be nice if we could simple instruct the affected hosts to into maintenance mode directly and we hoped that VCSA would (if available) move things for us. Sadly that is not the case.

So in a way it is shame that vCenter's monitoring and checking doesn't extend to : "Ooo Look that host is trying to go into maintenance mode, let me move these VMs first".

0 Kudos
StephenMoll
Expert
Expert

We stumbled across an approach that works quite well (for us anyway).

One of the niggles we had with our UPS shutdown tool was that whilst it was shutting down or killing VMs prior to migrating the rest and shutting down the host, it was sometimes fighting against another system management tool that was re-starting some VMs and Horizon View which was re-starting VMs that were members of any desktop pools.

We found that the first thing to do was to log into the host and initiate an "Enter Maintenance Mode" task. Whilst this didn't trigger any migrations, it did prevent any VMs from being powered on.

The tool then shut down or powered-off any VMs not required.

When the only VMs left are the ones requiring migration, an "Enter Maintenance Mode" task is initiated on vCenter, this would trigger migrations, and once the host was in a state where maintenance mode entry could proceed, then both tasks would complete successfully and the host could then be powered down.

A quick additional question:

When an maintenance mode entry is initiated through vCenter, if it is determined that one or more VMs cannot be migrated, does this mean no VMs will migrate at all, or will at least those that can move?

0 Kudos
sjesse
Leadership
Leadership

From my experience it will move the ones it can move and but will prevent the maintenance mode from completing until the ones that are stuck are taking care of.

0 Kudos
StephenMoll
Expert
Expert

Yes, I think you're right. Our observation was tainted by a miss configuration of some storage settings.

I would be interested to know some more about the logic and decision making behind DRS recommendations, I may ask in another topic.

0 Kudos
sjesse
Leadership
Leadership

I think there is a more updated out there, but there is the below link I've seen before.

DRS Deepdive – Yellow Bricks | Yellow Bricks

check out some of the videos from vmworld which they talk about drs 2.0 which is going to be different, I think drs really hasn't updated that much in the past.

0 Kudos
StephenMoll
Expert
Expert

I will do that. I have Frank and Niel's "Clustering Deep Dive" I'll have a look in there too.

I missed out on VMworld this year, I managed to get to Vegas for 2018 (as well as Dell Tech' World earlier in the year). I may try and get to the Europe one this year, but will take a look at the video you suggest, as it would be useful to see where DRS is going.

My interest stems from some rather complex and stringent affinity rule requirements we have to meet, and where this conflicts with VMs pinned by vGPU pass-through (some kit still on VS6.5). We are required to be able to explain what happens in any situation with a strong lean towards having deterministic behaviour. So an understanding of any algorithmic approach taken by DRS in assessing vMotion recommendations would be useful.

0 Kudos