9-08-08T17:03:47+0530",
"description": "starting maintenance for host 1",
"domain": "ROOT",
"domainid": "712762c6-b2b0-11e9-831d-34e12d5f623e",
"id": "3e305f6f-d91f-47d3-be74-bcc37c1d6995&quo
So then I guess the correct way to check if host is in maintenance is through
querying DB.
Sent from my iPhone
> On 08-Aug-2019, at 12:03 PM, Anurag Awasthi
> wrote:
>
> Hi Rakesh,
>
> Andrija is correct. Internally, all the API call does is move the host to a
> different state. Periodicall
Hi Rakesh,
Andrija is correct. Internally, all the API call does is move the host to a
different state. Periodically (ping.interval duration apart) MS would attempt
migration of VMs. Once the host has zero running VMs and no VM in failure/error
state it would be marked in maintenance mode.
Re
Rakesh,
I'm not quite sure if this is a bug/misbehaviour, but it is indeed a
confusing one.
When you ask a host to go to maintenance mode, , you are using
prepareHostForMaintenance as you said, and this will trigger the host to go
into the "PrepareForMaintenance" state... so the job does indeed c
Hello Anurag
Thanks for the reply. The host does transit to maintenance mode eventually but
the asynchronous job status never changes. Right now I'm periodically fetching
the resource_state from DB to see if it changes to "Maintenance". Is there any
better way to do it like using triggers or
Hi Rakesh,
You seem to be doing the right thing. I think what you have encoutered is a bug
in prepareForMaintenance API. The host tends to be stuck in that state in some
scenarios. Perhaps, when a VM enters an error state. I would advise canceling
maintenance mode and examining what states the
