OpenStack Compute (nova)

Bug #1798805
Comment #3

Comment 3 for bug 1798805

Revision history for this message

Eric Miller (erickmiller) wrote on 2018-10-19:

@Matt - Since we are using Kolla-Ansible to deploy a container-based OpenStack, we stop the docker container that is running the nova-compute process(es), so it is effectively the same as stopping the nova-compute process (gracefully) on a non-containerized OpenStack.

I actually tried both waiting and not waiting for the status to appear as "down" in the nova service-list output. The same result occurred.

"openstack start VM001" was used to power on the VM (equivalent of nova start VM001). I thought that powering on triggered a scheduler event, but I guess I was wrong.

Regarding the nova reset-state, there are a few different states, including "task_state", which is where the "powering-on" state is located. The nova reset-state command resets the "vm_state" field in the instances table in the nova database (unless I'm mistaken - please correct if I'm wrong). Is there a command to reset the "task_state"? I had to do it manually in the database to recover.

Btw, it appears that the "openstack start VM001" command retries quite a few times since I started the nova_compute docker container a few minutes after stopping the container and the VM powered on and the task_state was set appropriately.

Let me re-state the issue.

We were looking for a way to put a host in maintenance mode where 1) no additional VMs could start on the host, 2) we could live migrate powered on VMs off this host, and 3) migrate powered off VMs off this host. So essentially what vSphere's maintenance mode function does.

We thought we could accomplish by:
#1 by stopping the nova compute service, but that doesn't work for VMs already assigned to that host.
#2 scripting, or using the "Migrate Host" option in Horizon after disabling the compute service on the host.
#3 ?? - seems impossible with the current API - the compute node assigned to a VM apparently can't be changed, as far as I have found, with the API/CLI/etc. This seems to be the "node" column in the instances table in the nova database, and can be changed manually, which works, but it seems like there should be a better way with the API/CLI/etc.

I thought that the "openstack host set" command would have everything we needed, and saw that it has --enable/--disable and --enable-maintanance/--disable-maintenance, but the latter seems to be only for Xen, and not KVM? The --enable/--disable doesn't seem to work either. All parameters end with a 400 error. So, my guess is that all of these parameters are for Xen and not KVM?

To re-iterate: #1 likely requires using the "openstack host set --disable <host>" command to disable scheduling of "new" VMs, #2 is possible, and #3 requires manual database changes. Any suggested alternatives?

Shelving doesn't appear to be the right approach, and unshelving powers-on a VM automatically after unshelving (at least from the Horizon interface), so that's no good.

Thanks!

Eric

I actually tried both waiting and not waiting for the status to appear as "down" in the nova service-list output.  The same result occurred.

"openstack start VM001" was used to power on the VM (equivalent of nova start VM001).  I thought that powering on triggered a scheduler event, but I guess I was wrong.

Regarding the nova reset-state, there are a few different states, including "task_state", which is where the "powering-on" state is located.  The nova reset-state command resets the "vm_state" field in the instances table in the nova database (unless I'm mistaken - please correct if I'm wrong).  Is there a command to reset the "task_state"?  I had to do it manually in the database to recover.

Let me re-state the issue.

We were looking for a way to put a host in maintenance mode where 1) no additional VMs could start on the host, 2) we could live migrate powered on VMs off this host, and 3) migrate powered off VMs off this host.  So essentially what vSphere's maintenance mode function does.

We thought we could accomplish by:
#1 by stopping the nova compute service, but that doesn't work for VMs already assigned to that host.
#2 scripting, or using the "Migrate Host" option in Horizon after disabling the compute service on the host.
#3 ?? - seems impossible with the current API - the compute node assigned to a VM apparently can't be changed, as far as I have found, with the API/CLI/etc.  This seems to be the "node" column in the instances table in the nova database, and can be changed manually, which works, but it seems like there should be a better way with the API/CLI/etc.

I thought that the "openstack host set" command would have everything we needed, and saw that it has --enable/--disable and --enable-maintanance/--disable-maintenance, but the latter seems to be only for Xen, and not KVM?  The --enable/--disable doesn't seem to work either.  All parameters end with a 400 error.  So, my guess is that all of these parameters are for Xen and not KVM?

To re-iterate:  #1 likely requires using the "openstack host set --disable <host>" command to disable scheduling of "new" VMs, #2 is possible, and #3 requires manual database changes.  Any suggested alternatives?

Shelving doesn't appear to be the right approach, and unshelving powers-on a VM automatically after unshelving (at least from the Horizon interface), so that's no good.

Thanks!

Eric