you mean to say logging by root on single host ? if yes you can not put single host on m-mode
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.
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.
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".
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?
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.
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.
I think there is a more updated out there, but there is the below link I've seen before.
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.
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.