Die Migration der OpenStack-Instanz schlägt fehl

Die Migration der OpenStack-Instanz schlägt fehl

Die OpenStack-Migration zwischen zwei Hosts schlägt fehl. OpenStack Ussuri wird verwendet. Auf beiden Hosts laufen VMs und sie können neue VMs hosten.

Beide Hosts werden in der Compute-Dienstliste als aktiv und verfügbar angezeigt:

darren@jacob:admin:~$ openstack compute service list
+--------------------------------------+----------------+--------+----------+---------+-------+--    --------------------------+
| ID                                   | Binary         | Host   | Zone     | Status  | State | Updated At                 |
+--------------------------------------+----------------+--------+----------+---------+-------+----------------------------+
| 65640c54-641f-4cbf-91ba-dac39764ac31 | nova-scheduler | jacob  | internal | enabled | up    | 2021-01-15T23:57:22.000000 |
| 0aa0b80b-09e6-4e61-b222-dbf62b43ddda | nova-conductor | jacob  | internal | enabled | up    | 2021-01-15T23:57:26.000000 |
| f4dce946-94cf-482a-83d2-b32f1c7f87b5 | nova-compute   | joseph | nova     | enabled | up    | 2021-01-15T23:57:19.000000 |
| 2b149fe0-9b9b-44b8-8d70-9fa5cf3b968b | nova-compute   | judah  | nova     | enabled | up    | 2021-01-15T23:57:27.000000 |
+--------------------------------------+----------------+--------+----------+---------+-------+----------------------------+

Hier ein Auszug des Fehlers des Controllers /var/log/nova/nova-conductor.log:

2021-01-15 15:39:43.263 30830 ERROR nova.conductor.tasks.migrate [req-a62d9ff4-be8b-4870-81a4-ebaf1c85ce37 993afae9dd9746b48f72fcafd974aef7 e98eaaf8e7ff403cb1180e9e29148890 - default default] [instance: 001f9cad-25ca-4f2d-b32c-01953d854dc5] Unable to find record for source node joseph.mcgrandle.com on joseph: nova.exception.ComputeHostNotFound: Compute host joseph could not be found.
2021-01-15 15:39:43.263 30830 WARNING nova.scheduler.utils [req-a62d9ff4-be8b-4870-81a4-ebaf1c85ce37 993afae9dd9746b48f72fcafd974aef7 e98eaaf8e7ff403cb1180e9e29148890 - default default] Failed to compute_task_migrate_server: Compute host joseph could not be found.: nova.exception.ComputeHostNotFound: Compute host joseph could not be found.
2021-01-15 15:39:43.264 30830 WARNING nova.scheduler.utils [req-a62d9ff4-be8b-4870-81a4-ebaf1c85ce37 993afae9dd9746b48f72fcafd974aef7 e98eaaf8e7ff403cb1180e9e29148890 - default default] [instance: 001f9cad-25ca-4f2d-b32c-01953d854dc5] Setting instance to ACTIVE state.: nova.exception.ComputeHostNotFound: Compute host joseph could not be found.
2021-01-15 15:39:43.318 30830 ERROR oslo_messaging.rpc.server [req-a62d9ff4-be8b-4870-81a4-ebaf1c85ce37 993afae9dd9746b48f72fcafd974aef7 e98eaaf8e7ff403cb1180e9e29148890 - default default] Exception during message handling: nova.exception.ComputeHostNotFound: Compute host joseph could not be found.

Ich habe versucht, die Nova-Datenbank neu zu füllen # su -s /bin/sh -c "nova-manage db sync" nova und auch die Compute-Hosts erneut zu ermitteln: # su -s /bin/sh -c "nova-manage cell_v2 discover_hosts --verbose" nova

Aber nichts scheint einen Unterschied zu machen. Danke für alle Hinweise und Hilfe.

Update: hier ist die Ausgabe der angeforderten Befehle:

darren@jacob:admin:~$ sudo nova-manage cell_v2 list_hosts
+-----------+--------------------------------------+----------+
| Cell Name |              Cell UUID               | Hostname |
+-----------+--------------------------------------+----------+
|   cell1   | 9095885b-466f-41d4-9c85-45b5af7b5ce2 |  joseph  |
|   cell1   | 9095885b-466f-41d4-9c85-45b5af7b5ce2 |  judah   |
|   cell1   | 9095885b-466f-41d4-9c85-45b5af7b5ce2 |  reuben  |
+-----------+--------------------------------------+----------+
darren@jacob:admin:~$ sudo nova-manage cell_v2 list_cells
+-------+--------------------------------------+-------------------------------------+--------------------------------------------+----------+
|  Name |                 UUID                 |            Transport URL            |            Database Connection             | Disabled |
+-------+--------------------------------------+-------------------------------------+--------------------------------------------+----------+
| cell0 | 00000000-0000-0000-0000-000000000000 |                none:/               | mysql+pymysql://nova:****@jacob/nova_cell0 |  False   |
| cell1 | 9095885b-466f-41d4-9c85-45b5af7b5ce2 | rabbit://openstack:****@jacob:5672/ |    mysql+pymysql://nova:****@jacob/nova    |  False   |
+-------+--------------------------------------+-------------------------------------+--------------------------------------------+----------+

und hier ist die aktualisierte compute service listAusgabe nach dem Hinzufügen reuben:

darren@jacob:admin:~$ openstack compute service list
+--------------------------------------+----------------+--------+----------+---------+-------+----------------------------+
| ID                                   | Binary         | Host   | Zone     | Status  | State | Updated At                 |
+--------------------------------------+----------------+--------+----------+---------+-------+----------------------------+
| 65640c54-641f-4cbf-91ba-dac39764ac31 | nova-scheduler | jacob  | internal | enabled | up    | 2021-01-26T08:04:07.000000 |
| 0aa0b80b-09e6-4e61-b222-dbf62b43ddda | nova-conductor | jacob  | internal | enabled | up    | 2021-01-26T08:04:08.000000 |
| f4dce946-94cf-482a-83d2-b32f1c7f87b5 | nova-compute   | joseph | nova     | enabled | up    | 2021-01-26T08:04:09.000000 |
| 2b149fe0-9b9b-44b8-8d70-9fa5cf3b968b | nova-compute   | judah  | nova     | enabled | up    | 2021-01-26T08:04:08.000000 |
| d306fe4f-1d12-41b7-a2c9-8f856247268b | nova-compute   | reuben | nova     | enabled | up    | 2021-01-26T08:04:15.000000 |
+--------------------------------------+----------------+--------+----------+---------+-------+----------------------------+

Antwort1

Ich stelle gerade dasselbe Verhalten auf einer Ussuri-Plattform fest. Aber nur bei einigen wenigen Instanzen. Was mir aufgefallen ist, ist, dass diese Instanzen im Image-Feld (wenn Sie eine OpenStack-Server-Show durchführen) nicht das Tag (N/A (vom Volume gebootet) haben. In unserem Fall sind alle unsere Instanzen mit einem Boot vom Volume (nicht flüchtig) konfiguriert. Und diese Instanzen scheinen als flüchtig gekennzeichnet zu sein. Ich habe versucht, eine --block-migration durchzuführen, aber es funktioniert nicht.

Geht es Ihnen genauso?

Grüße

verwandte Informationen