{"id":19134,"date":"2023-11-09T00:08:01","date_gmt":"2023-11-08T21:08:01","guid":{"rendered":"https:\/\/kifarunix.com\/?p=19134"},"modified":"2024-03-10T15:11:29","modified_gmt":"2024-03-10T12:11:29","slug":"how-to-safely-reboot-openstack-compute-node","status":"publish","type":"post","link":"https:\/\/kifarunix.com\/how-to-safely-reboot-openstack-compute-node\/","title":{"rendered":"How to Safely Reboot OpenStack Compute Node"},"content":{"rendered":"\n<p>How can I safely reboot OpenStack compute node? In an OpenStack environment, the compute nodes are the workhorses responsible for running virtual machines and managing compute resources. However, there may be situations where you need to reboot a compute node for maintenance or troubleshooting. Performing this task safely is crucial to avoid disruption to your cloud services. This blog post will guide you through the steps to safely reboot an OpenStack compute node, minimizing downtime and ensuring a smooth transition while maintaining the integrity of your cloud infrastructure.<\/p>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2>Table of Contents<\/h2><nav><ul><li><a href=\"#reboot-open-stack-compute-node-safely\">Reboot OpenStack Compute Node Safely<\/a><ul><li><a href=\"#disable-instance-scheduling-on-compute-node\">Disable Instance Scheduling on Compute Node<\/a><\/li><li><a href=\"#migrate-instances-v-ms-to-other-compute-nodes\">Migrate Instances\/VMs to Other Compute Nodes<\/a><ul><li><a href=\"#cold-instance-migration\">Cold Instance Migration<\/a><\/li><li><a href=\"#live-instance-migration\">Live Instance Migration<\/a><\/li><li><a href=\"#get-a-list-of-running-instances-on-compute-node-to-reboot\">Get a List of Running Instances on Compute Node to Reboot<\/a><\/li><li><a href=\"#get-a-list-of-compute-nodes\">Get a List of Compute Nodes<\/a><\/li><li><a href=\"#migrate-open-stack-instances-to-other-compute-nodes\">Migrate OpenStack Instances to Other Compute Nodes<\/a><\/li><\/ul><\/li><li><a href=\"#stop-all-open-stack-services-running-on-the-compute-node\">Stop all OpenStack services running on the compute node<\/a><\/li><li><a href=\"#reboot-open-stack-compute-node\">Reboot OpenStack Compute Node<\/a><\/li><li><a href=\"#start-open-stack-services\">Start OpenStack Services<\/a><\/li><li><a href=\"#re-enable-instance-scheduling-on-the-compute-node\">Re-Enable Instance Scheduling on the Compute Node<\/a><\/li><li><a href=\"#optional-migrate-instances-back-to-original-nodes\">[Optional] Migrate Instances Back to Original Nodes<\/a><\/li><\/ul><\/li><\/ul><\/nav><\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"reboot-open-stack-compute-node-safely\">Reboot OpenStack Compute Node Safely<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"disable-instance-scheduling-on-compute-node\">Disable Instance Scheduling on Compute Node<\/h3>\n\n\n\n<p>In an active environment where you cannot control who is creating OpenStack instances, you won&#8217;t one instances being launched on the node that you have marked for reboot.<\/p>\n\n\n\n<p>As such, you need to ensure that you disable any instance scheduling on the same node marked for reboot.<\/p>\n\n\n\n<p>You can disable instance scheduling on the respective compute node <strong>by disabling the nova compute service<\/strong> in that host either from the CLI or from OpenStack horizon;<\/p>\n\n\n\n<p>You can list the services using the command below;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack compute service list --host compute02<\/code><\/pre>\n\n\n\n<pre class=\"scroll-sz\"><code>+--------------------------------------+--------------+-----------+------+---------+-------+----------------------------+\n| ID                                   | Binary       | Host      | Zone | Status  | State | Updated At                 |\n+--------------------------------------+--------------+-----------+------+---------+-------+----------------------------+\n| 464698d3-0da5-44cb-ba91-7d6782b2cff9 | nova-compute | compute02 | nova | enabled | up    | 2023-11-07T21:15:50.000000 |\n+--------------------------------------+--------------+-----------+------+---------+-------+----------------------------+\n<\/code><\/pre>\n\n\n\n<p>To disable instance scheduling on a compute node from the CLI, run the command below;<\/p>\n\n\n\n<p>(Note that we deployed our OpenStack using Kolla-Ansible)<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>source $HOME\/kolla-ansible\/bin\/activate\nsource \/etc\/kolla\/admin-openrc.sh<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack compute service set &#91;-h] &#91;--enable | --disable] &#91;--disable-reason &lt;reason&gt;] &#91;--up | --down] &lt;host&gt; &lt;service&gt;<\/code><\/pre>\n\n\n\n<p>For example, to disable nova compute service on compute02 node;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack compute service set --disable --disable-reason for-safe-reboot compute02 nova-compute<\/code><\/pre>\n\n\n\n<p>You can do the same from Horizon, <strong>Admin &gt; Compute &gt; Hypervisors &gt; Select the Host &gt; Actions &gt; Disable service<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"migrate-instances-v-ms-to-other-compute-nodes\">Migrate Instances\/VMs to Other Compute Nodes<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\" id=\"cold-instance-migration\">Cold Instance Migration<\/h4>\n\n\n\n<p>Cold migration, or non-live migration, involves shutting down a running instance before migrating it from the source compute node to the destination compute node. Cold migration necessitates a brief interruption in the instance&#8217;s operation. The migrated instance retains access to its original volumes and IP addresses.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\" id=\"live-instance-migration\">Live Instance Migration<\/h4>\n\n\n\n<p>Live migration seamlessly shifts the instance from the source Compute node to the destination Compute node without any need for a shutdown, all while preserving state consistency throughout the process.<\/p>\n\n\n\n<p>If your OpenStack environment supports live migration (<em>you can check <a href=\"https:\/\/docs.openstack.org\/nova\/latest\/user\/support-matrix.html\" target=\"_blank\" rel=\"noreferrer noopener\">Feature Support Matrix<\/a>&nbsp;to determine which hypervisors support live-migration.<\/em>), consider migrating VM instances from the compute node you plan to reboot to other available compute nodes. Live migration allows VMs to remain running during the process, minimizing downtime.<\/p>\n\n\n\n<p>Live migrations can be categorized based on how they handle instance storage:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Shared Storage-Based Live Migration:<\/strong> This type of migration involves instances with ephemeral disks stored on shared storage accessible to both the source and destination hosts. This method is faster and more efficient than block live migration because the instance&#8217;s disk images are already accessible to the destination host.<\/li>\n\n\n\n<li><strong>Block Live Migration (Block Migration):<\/strong> Block migration is used when instances have ephemeral disks (e.g. <strong><em>instances booting from image<\/em><\/strong>) that are not shared between the source and destination hosts. It&#8217;s important to note that block migration is not compatible with read-only devices like CD-ROMs and Configuration Drive (config_drive). This method is slower and more resource-intensive than shared storage-based live migration.<\/li>\n\n\n\n<li><strong>Volume-Backed Live Migration:<\/strong> In this scenario, instances use volumes for storage instead of ephemeral disks. This method is faster than block live migration because the disk images do not need to be copied. However, it is still slower than shared storage-based live migration because the block storage volumes need to be attached to the destination host. Block storage backends such as Ceph, Cinder, GlusterFS e.t.c support volume-backed live migration <\/li>\n<\/ol>\n\n\n\n<p>These classifications help determine the method of live migration suitable for your specific instance and storage setup.<\/p>\n\n\n\n<p>You can do the migration from the horizon dashboard or from the command line.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\" id=\"get-a-list-of-running-instances-on-compute-node-to-reboot\">Get a List of Running Instances on Compute Node to Reboot<\/h4>\n\n\n\n<p>To begin with, get a list of all instances running on the compute node you need to reboot. For example, below is a list of instances running on our compute02 node;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack server list --host compute02 --all-projects<\/code><\/pre>\n\n\n\n<p>Sample output;<\/p>\n\n\n\n<pre class=\"scroll-sz\"><code>+--------------------------------------+-----------------+--------+-------------------------+--------+---------+\n| ID                                   | Name            | Status | Networks                | Image  | Flavor  |\n+--------------------------------------+-----------------+--------+-------------------------+--------+---------+\n| ee54d242-4fdd-4a3b-8ee5-30b3171e1df6 | gracious_turing | ACTIVE | DEMO_NET=192.168.50.123 | cirros | custom1 |\n+--------------------------------------+-----------------+--------+-------------------------+--------+---------+\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\" id=\"get-a-list-of-compute-nodes\">Get a List of Compute Nodes<\/h4>\n\n\n\n<p>Similarly, you can also list compute nodes available (just in case you want to explicitly specify which node to migrate an instance to, otherwise the nova scheduler takes care of all the decisions on where to place the instance being migrated, just incase you have multiple compute nodes).<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack hypervisor list<\/code><\/pre>\n\n\n\n<pre class=\"scroll-sz\"><code>+--------------------------------------+---------------------+-----------------+-----------------+-------+\n| ID                                   | Hypervisor Hostname | Hypervisor Type | Host IP         | State |\n+--------------------------------------+---------------------+-----------------+-----------------+-------+\n| 6aa76044-d456-4c3b-8f28-fcfc7e79b658 | compute01           | QEMU            | 192.168.200.202 | up    |\n| 7365f5eb-62e1-477e-bf45-8f77ea98802a | compute02           | QEMU            | 192.168.200.203 | up    |\n+--------------------------------------+---------------------+-----------------+-----------------+-------+\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\" id=\"migrate-open-stack-instances-to-other-compute-nodes\">Migrate OpenStack Instances to Other Compute Nodes<\/h4>\n\n\n\n<p>Once you have the information, you can now proceed to migrate an instance.<\/p>\n\n\n\n<p>As already mentioned, depending on the criticality of the operations\/services handled  by an instance, you can choose to go the cold or the live way.<\/p>\n\n\n\n<p>OpenStack instances can be migrated using the command, <strong><code>openstack server migrate<\/code><\/strong>.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack server migrate --help<\/code><\/pre>\n\n\n\n<pre class=\"scroll-box\"><code>usage: openstack server migrate [-h] [--live-migration] [--host <hostname>] [--shared-migration | --block-migration] [--disk-overcommit | --no-disk-overcommit]\n                                [--wait]\n                                <server>\n\nMigrate server to different host. A migrate operation is implemented as a resize operation using the same flavor as the old server. This means that, like resize, migrate\nworks by creating a new server using the same flavor and copying the contents of the original disk into a new one. As with resize, the migrate operation is a two-step\nprocess for the user: the first step is to perform the migrate, and the second step is to either confirm (verify) success and release the old server, or to declare a\nrevert to release the new server and restart the old one.\n\npositional arguments:\n  <server>      Server (name or ID)\n\noptions:\n  -h, --help            show this help message and exit\n  --live-migration      Live migrate the server; use the ``--host`` option to specify a target host for the migration which will be validated by the scheduler\n  --host <hostname>\n                        Migrate the server to the specified host. (supported with --os-compute-api-version 2.30 or above when used with the --live-migration option)\n                        (supported with --os-compute-api-version 2.56 or above when used without the --live-migration option)\n  --shared-migration    Perform a shared live migration (default before --os-compute-api-version 2.25, auto after)\n  --block-migration     Perform a block live migration (auto-configured from --os-compute-api-version 2.25)\n  --disk-overcommit     Allow disk over-commit on the destination host(supported with --os-compute-api-version 2.24 or below)\n  --no-disk-overcommit  Do not over-commit disk on the destination host (default)(supported with --os-compute-api-version 2.24 or below)\n  --wait                Wait for migrate to complete\n<\/code><\/pre>\n\n\n\n<p>So, let&#8217;s live migrate my instance, <strong><code>gracious_turing<\/code><\/strong>, with the UUID, <strong><code>ee54d242-4fdd-4a3b-8ee5-30b3171e1df6<\/code><\/strong>.<\/p>\n\n\n\n<p>Note that the instance is booting from an image and no shared storage, hence, we will do block-based live migration;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack server migrate --live-migration --block-migration gracious_turing --wait<\/code><\/pre>\n\n\n\n<p>If you check on horizon, under instances, you will see the instance status as migrating.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1902\" height=\"578\" src=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/migrating-live-instance.png\" alt=\"\" class=\"wp-image-19158\" title=\"\" srcset=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/migrating-live-instance.png?v=1699472894 1902w, https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/migrating-live-instance-768x233.png?v=1699472894 768w, https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/migrating-live-instance-1536x467.png?v=1699472894 1536w\" sizes=\"(max-width: 1902px) 100vw, 1902px\" \/><\/figure>\n\n\n\n<p>After a short while, the instance migration should be completed. Since I have only two compute nodes, the instance should have been migrated to compute01;<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1270\" height=\"572\" src=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/instance-migrated.png\" alt=\"\" class=\"wp-image-19161\" title=\"\" srcset=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/instance-migrated.png?v=1699473254 1270w, https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/instance-migrated-768x346.png?v=1699473254 768w\" sizes=\"(max-width: 1270px) 100vw, 1270px\" \/><\/figure>\n\n\n\n<p>If you want to do cold migration, then you can shut down an instance an migrate them.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"stop-all-open-stack-services-running-on-the-compute-node\">Stop all OpenStack services running on the compute node<\/h3>\n\n\n\n<p>Once the instances on the compute node are migrated, you can now login to compute node and stop all openstack services.<\/p>\n\n\n\n<p>If you are using ansible, then you can use it to check and stop the services on the compute node.<\/p>\n\n\n\n<p>For example, let&#8217;s verify, from the controller\/ansible node, all openstack services running on our compute02<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible -i multinode -m raw -a \"docker ps\" compute02<\/code><\/pre>\n\n\n\n<pre class=\"scroll-box\"><code>compute02 | CHANGED | rc=0 >>\nCONTAINER ID   IMAGE                                                                     COMMAND                  CREATED      STATUS                PORTS     NAMES\nefe871ef9fbf   quay.io\/openstack.kolla\/zun-cni-daemon:2023.1-ubuntu-jammy                \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             zun_cni_daemon\nf6155141547b   quay.io\/openstack.kolla\/zun-compute:2023.1-ubuntu-jammy                   \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             zun_compute\n143e53a3b9de   quay.io\/openstack.kolla\/ceilometer-compute:2023.1-ubuntu-jammy            \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             ceilometer_compute\nda3bb6f8f71b   quay.io\/openstack.kolla\/kuryr-libnetwork:2023.1-ubuntu-jammy              \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             kuryr\n7fa1016b0acf   quay.io\/openstack.kolla\/neutron-openvswitch-agent:2023.1-ubuntu-jammy     \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             neutron_openvswitch_agent\n98016d47c4d6   quay.io\/openstack.kolla\/openvswitch-vswitchd:2023.1-ubuntu-jammy          \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             openvswitch_vswitchd\n2676319cfbdc   quay.io\/openstack.kolla\/openvswitch-db-server:2023.1-ubuntu-jammy         \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             openvswitch_db\n8b750f8dc593   quay.io\/openstack.kolla\/nova-compute:2023.1-ubuntu-jammy                  \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             nova_compute\n84397013842c   quay.io\/openstack.kolla\/nova-libvirt:2023.1-ubuntu-jammy                  \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             nova_libvirt\n3768d9da5ab7   quay.io\/openstack.kolla\/nova-ssh:2023.1-ubuntu-jammy                      \"dumb-init --single-\u2026\"   3 days ago   Up 3 days (healthy)             nova_ssh\nec5a5dd65cb4   quay.io\/openstack.kolla\/iscsid:2023.1-ubuntu-jammy                        \"dumb-init --single-\u2026\"   3 days ago   Up 3 days                       iscsid\nf4185c0884ae   quay.io\/openstack.kolla\/prometheus-libvirt-exporter:2023.1-ubuntu-jammy   \"dumb-init --single-\u2026\"   3 days ago   Up 3 days                       prometheus_libvirt_exporter\nd9942be630fa   quay.io\/openstack.kolla\/prometheus-cadvisor:2023.1-ubuntu-jammy           \"dumb-init --single-\u2026\"   3 days ago   Up 3 days                       prometheus_cadvisor\n04fec61c5671   quay.io\/openstack.kolla\/prometheus-node-exporter:2023.1-ubuntu-jammy      \"dumb-init --single-\u2026\"   3 days ago   Up 3 days                       prometheus_node_exporter\n221098bf97e7   quay.io\/openstack.kolla\/cron:2023.1-ubuntu-jammy                          \"dumb-init --single-\u2026\"   3 days ago   Up 3 days                       cron\n36fc2702d398   quay.io\/openstack.kolla\/kolla-toolbox:2023.1-ubuntu-jammy                 \"dumb-init --single-\u2026\"   3 days ago   Up 3 days                       kolla_toolbox\n80f42d83c6f7   quay.io\/openstack.kolla\/fluentd:2023.1-ubuntu-jammy                       \"dumb-init --single-\u2026\"   3 days ago   Up 3 days                       fluentd\n<\/code><\/pre>\n\n\n\n<p>The easiest way to stop these Docker services, remember we <a href=\"https:\/\/kifarunix.com\/deploy-multinode-openstack-using-kolla-ansible\/\" target=\"_blank\" rel=\"noreferrer noopener\">deployed our OpenStack using Kolla-Ansible<\/a>, simply stop the docker service.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible -i multinode -m raw -a \"sudo systemctl stop docker.service docker.socket\" compute02<\/code><\/pre>\n\n\n\n<p>If you are not using configuration managemen tools such Ansible, be sure to stop <strong>nova-compute<\/strong> and <strong>neutron-linuxbridge-agent<\/strong> when you stop the services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"reboot-open-stack-compute-node\">Reboot OpenStack Compute Node<\/h3>\n\n\n\n<p>Next, reboot the compute node. Again, we will use Ansible in our setup;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible -i multinode -m raw -a \"sudo systemctl reboot -i\" compute02<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"start-open-stack-services\">Start OpenStack Services<\/h3>\n\n\n\n<p>If you are using configuration management tools such as Ansible, chances are high that the OpenStack services will be started automatically after reboot.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ansible -i multinode -m raw -a \"docker ps\" compute02<\/code><\/pre>\n\n\n\n<pre class=\"scroll-box\"><code>compute02 | CHANGED | rc=0 >>\nCONTAINER ID   IMAGE                                                                     COMMAND                  CREATED      STATUS                     PORTS     NAMES\nefe871ef9fbf   quay.io\/openstack.kolla\/zun-cni-daemon:2023.1-ubuntu-jammy                \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (healthy)               zun_cni_daemon\nf6155141547b   quay.io\/openstack.kolla\/zun-compute:2023.1-ubuntu-jammy                   \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (healthy)               zun_compute\n143e53a3b9de   quay.io\/openstack.kolla\/ceilometer-compute:2023.1-ubuntu-jammy            \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (unhealthy)             ceilometer_compute\nda3bb6f8f71b   quay.io\/openstack.kolla\/kuryr-libnetwork:2023.1-ubuntu-jammy              \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (healthy)               kuryr\n7fa1016b0acf   quay.io\/openstack.kolla\/neutron-openvswitch-agent:2023.1-ubuntu-jammy     \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (healthy)               neutron_openvswitch_agent\n98016d47c4d6   quay.io\/openstack.kolla\/openvswitch-vswitchd:2023.1-ubuntu-jammy          \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (healthy)               openvswitch_vswitchd\n2676319cfbdc   quay.io\/openstack.kolla\/openvswitch-db-server:2023.1-ubuntu-jammy         \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (healthy)               openvswitch_db\n8b750f8dc593   quay.io\/openstack.kolla\/nova-compute:2023.1-ubuntu-jammy                  \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (healthy)               nova_compute\n84397013842c   quay.io\/openstack.kolla\/nova-libvirt:2023.1-ubuntu-jammy                  \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (healthy)               nova_libvirt\n3768d9da5ab7   quay.io\/openstack.kolla\/nova-ssh:2023.1-ubuntu-jammy                      \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes (healthy)               nova_ssh\nec5a5dd65cb4   quay.io\/openstack.kolla\/iscsid:2023.1-ubuntu-jammy                        \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes                         iscsid\nf4185c0884ae   quay.io\/openstack.kolla\/prometheus-libvirt-exporter:2023.1-ubuntu-jammy   \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes                         prometheus_libvirt_exporter\nd9942be630fa   quay.io\/openstack.kolla\/prometheus-cadvisor:2023.1-ubuntu-jammy           \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes                         prometheus_cadvisor\n04fec61c5671   quay.io\/openstack.kolla\/prometheus-node-exporter:2023.1-ubuntu-jammy      \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes                         prometheus_node_exporter\n221098bf97e7   quay.io\/openstack.kolla\/cron:2023.1-ubuntu-jammy                          \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes                         cron\n36fc2702d398   quay.io\/openstack.kolla\/kolla-toolbox:2023.1-ubuntu-jammy                 \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes                         kolla_toolbox\n80f42d83c6f7   quay.io\/openstack.kolla\/fluentd:2023.1-ubuntu-jammy                       \"dumb-init --single-\u2026\"   3 days ago   Up 3 minutes                         fluentd\n<\/code><\/pre>\n\n\n\n<p>If not using any configuration management, be sure to start all Openstack services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"re-enable-instance-scheduling-on-the-compute-node\">Re-Enable Instance Scheduling on the Compute Node<\/h3>\n\n\n\n<p>Once the node is up and all the services are up;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack hypervisor list<\/code><\/pre>\n\n\n\n<pre class=\"scroll-sz\"><code>+--------------------------------------+---------------------+-----------------+-----------------+-------+\n| ID                                   | Hypervisor Hostname | Hypervisor Type | Host IP         | State |\n+--------------------------------------+---------------------+-----------------+-----------------+-------+\n| 6aa76044-d456-4c3b-8f28-fcfc7e79b658 | compute01           | QEMU            | 192.168.200.202 | up    |\n| 7365f5eb-62e1-477e-bf45-8f77ea98802a | compute02           | QEMU            | 192.168.200.203 | up    |\n+--------------------------------------+---------------------+-----------------+-----------------+-------+\n<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack compute service list --host compute02<\/code><\/pre>\n\n\n\n<pre class=\"scroll-sz\"><code>+--------------------------------------+--------------+-----------+------+----------+-------+----------------------------+\n| ID                                   | Binary       | Host      | Zone | Status   | State | Updated At                 |\n+--------------------------------------+--------------+-----------+------+----------+-------+----------------------------+\n| 464698d3-0da5-44cb-ba91-7d6782b2cff9 | nova-compute | compute02 | nova | disabled | up    | 2023-11-08T20:32:50.000000 |\n+--------------------------------------+--------------+-----------+------+----------+-------+----------------------------+\n<\/code><\/pre>\n\n\n\n<p>next, re-enable instance scheduling on the node;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>openstack compute service set --enable compute02 nova-compute<\/code><\/pre>\n\n\n\n<p>Or from the dashboard;<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1273\" height=\"699\" src=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/re-enable-instance-scheduling.png\" alt=\"\" class=\"wp-image-19164\" title=\"\" srcset=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/re-enable-instance-scheduling.png?v=1699476125 1273w, https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/re-enable-instance-scheduling-768x422.png?v=1699476125 768w\" sizes=\"(max-width: 1273px) 100vw, 1273px\" \/><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"optional-migrate-instances-back-to-original-nodes\">[Optional] Migrate Instances Back to Original Nodes<\/h3>\n\n\n\n<p>Once the node is up and running, you can choose to migrate the instances back to it or just let new instances scheduled on it.<\/p>\n\n\n\n<p>If you want to migrate, you can as done above, or do it from horizon;<\/p>\n\n\n\n<p>e.g to live migrate our instance, gracious_turing, back to compute02;<\/p>\n\n\n\n<figure class=\"wp-block-image size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"1264\" height=\"722\" src=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/re-migrate-instance.png\" alt=\"How to Safely Reboot OpenStack Compute Node\" class=\"wp-image-19165\" style=\"aspect-ratio:1.7506925207756232;width:820px;height:auto\" title=\"\" srcset=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/re-migrate-instance.png?v=1699476411 1264w, https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/re-migrate-instance-768x439.png?v=1699476411 768w\" sizes=\"(max-width: 1264px) 100vw, 1264px\" \/><\/figure>\n\n\n\n<p>Block live migration;<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1267\" height=\"587\" src=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/block-live-migration.png\" alt=\"\" class=\"wp-image-19166\" title=\"\" srcset=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/block-live-migration.png?v=1699476496 1267w, https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/block-live-migration-768x356.png?v=1699476496 768w\" sizes=\"(max-width: 1267px) 100vw, 1267px\" \/><\/figure>\n\n\n\n<p>Submit to begin the migration process.<\/p>\n\n\n\n<p>And voila, the instance is now running on the original compute node;<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"1393\" height=\"592\" src=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/instance-migrated-1.png\" alt=\"\" class=\"wp-image-19167\" title=\"\" srcset=\"https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/instance-migrated-1.png?v=1699476620 1393w, https:\/\/kifarunix.com\/wp-content\/uploads\/2023\/11\/instance-migrated-1-768x326.png?v=1699476620 768w\" sizes=\"(max-width: 1393px) 100vw, 1393px\" \/><\/figure>\n\n\n\n<p>And that completes our guide on how to reboot OpenStack compute node in a safe way.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>How can I safely reboot OpenStack compute node? In an OpenStack environment, the compute nodes are the workhorses responsible for running virtual machines and managing<\/p>\n","protected":false},"author":10,"featured_media":19169,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_lock_modified_date":false,"footnotes":""},"categories":[121,1885,1886],"tags":[7290,7289,7287,7288],"class_list":["post-19134","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-howtos","category-cloud-compute","category-openstack","tag-openstack-cold-migration","tag-openstack-live-migration","tag-reboot-openstack-compute-node","tag-safely-reboot-compute-node-openstack","generate-columns","tablet-grid-50","mobile-grid-100","grid-parent","grid-50","resize-featured-image"],"_links":{"self":[{"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/posts\/19134"}],"collection":[{"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/comments?post=19134"}],"version-history":[{"count":15,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/posts\/19134\/revisions"}],"predecessor-version":[{"id":20886,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/posts\/19134\/revisions\/20886"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/media\/19169"}],"wp:attachment":[{"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/media?parent=19134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/categories?post=19134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/tags?post=19134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}