[ English | Indonesia | Deutsch | 日本語 ]
Compute-Knotenausfällen und Wartung¶
Manchmal stürzt ein Compute-Knoten entweder unerwartet ab oder erfordert aus Wartungsgründen einen Neustart.
Geplante Wartung¶
Wenn Sie einen Compute-Knoten aufgrund geplanter Wartungsarbeiten, wie z. B. einem Software- oder Hardware-Upgrade, neu starten müssen, führen Sie die folgenden Schritte aus:
Deaktivieren Sie die Planung neuer VMs für den Knoten und geben Sie optional einen Kommentar zum Grund an:
# openstack compute service set --disable --disable-reason \ maintenance c01.example.com nova-compute
Stellen Sie sicher, dass alle bereitgestellten Instanzen vom Knoten entfernt wurden:
Wenn Ihre Cloud einen gemeinsamen Speicher verwendet:
Ermittelt eine Liste der Instanzen, die verschoben werden müssen:
# openstack server list --host c01.example.com --all-projects
Migrieren Sie alle Instanzen einzeln:
# openstack server migrate <uuid> --live c02.example.com
Wenn Ihre Cloud keinen gemeinsamen Speicher verwendet, führen Sie:
# openstack server migrate <uuid> --live --block-migration c02.example.com
Beenden Sie den Dienst
nova-compute:# stop nova-compute
Wenn Sie ein Konfigurationsmanagementsystem wie Puppet verwenden, das sicherstellt, dass der Dienst
nova-computeimmer läuft, können Sie dieinitDateien vorübergehend verschieben:# mkdir /root/tmp # mv /etc/init/nova-compute.conf /root/tmp # mv /etc/init.d/nova-compute /root/tmp
Fahren Sie Ihren Compute-Knoten herunter, führen Sie die Wartung durch und schalten Sie den Knoten wieder ein.
Starten Sie den Dienst
nova-compute:# start nova-compute
Sie können den Dienst
nova-computewieder aktivieren, indem Sie die Befehle rückgängig machen:# mv /root/tmp/nova-compute.conf /etc/init # mv /root/tmp/nova-compute /etc/init.d/
Aktivieren Sie die Planung von VMs für den Knoten:
# openstack compute service set --enable c01.example.com nova-compute
Optional können Sie die Instanzen wieder auf ihren ursprünglichen Compute-Knoten migrieren.
Nach einem Neustart des Compute-Knotens¶
Wenn Sie einen Computerknoten neu starten, überprüfen Sie zunächst, ob er erfolgreich gestartet wurde. Dazu gehört auch die Sicherstellung, dass der Dienst nova-compute läuft:
# ps aux | grep nova-compute
# status nova-compute
Stellen Sie auch sicher, dass er sich erfolgreich mit dem AMQP-Server verbunden hat:
# grep AMQP /var/log/nova/nova-compute.log
2013-02-26 09:51:31 12427 INFO nova.openstack.common.rpc.common [-] Connected to AMQP server on 199.116.232.36:5672
Nachdem der Compute-Knoten erfolgreich ausgeführt wurde, müssen Sie sich mit den Instanzen befassen, die auf diesem Compute-Knoten gehostet werden, da keine von ihnen ausgeführt wird. Abhängig von Ihrem SLA mit Ihren Benutzern oder Kunden müssen Sie möglicherweise jede Instanz starten und sicherstellen, dass sie korrekt startet.
Instanz¶
Sie können eine Liste von Instanzen erstellen, die auf dem Compute-Knoten bereitgestellt werden, indem Sie den folgenden Befehl ausführen:
# openstack server list --host c01.example.com --all-projects
Nachdem Sie die Liste haben, können Sie den Befehl openstack verwenden, um jede Instanz zu starten:
# openstack server reboot <server>
Bemerkung
Jedes Mal, wenn eine Instanz unerwartet heruntergefahren wird, kann es beim Booten zu Problemen kommen. Zum Beispiel könnte die Instanz ein fsck auf der Root-Partition erfordern. Wenn dies der Fall ist, kann der Benutzer die Dashboard VNC-Konsole verwenden, um dies zu beheben.
Wenn eine Instanz nicht bootet, d.h. virsh list zeigt die Instanz nie als Startversuch an, gehen Sie wie folgt vor auf dem Compute-Knoten:
# tail -f /var/log/nova/nova-compute.log
Versuchen Sie, den Befehl openstack server reboot erneut auszuführen. Du solltest eine Fehlermeldung sehen, warum die Instanz nicht booten konnte.
In den meisten Fällen ist der Fehler das Ergebnis von etwas in der XML-Datei von libvirt (/etc/libvirt/qemu/instance-xxxxxxxxxxxx.xml), das nicht mehr existiert. Sie können die Neuerstellung der XML-Datei sowie den Neustart der Instanz erzwingen, indem Sie den folgenden Befehl ausführen:
# openstack server reboot --hard <server>
Überprüfen und Wiederherstellen von Daten aus fehlerhaften Instanzen¶
In einigen Szenarien laufen Instanzen, sind aber über SSH nicht erreichbar und reagieren nicht auf Befehle. Die VNC-Konsole könnte einen Boot-Fehler oder Fehlermeldungen von Kernel-Panik anzeigen. Dies könnte ein Hinweis auf eine Beschädigung des Dateisystems auf der VM selbst sein. Wenn Sie Dateien wiederherstellen oder den Inhalt der Instanz überprüfen müssen, kann qemu-nbd verwendet werden, um die Festplatte zu mounten.
Warnung
Wenn Sie auf die Inhalte und Daten des Benutzers zugreifen oder diese anzeigen, holen Sie sich zuerst eine Genehmigung!
Um auf das Laufwerk der Instanz zuzugreifen (/var/lib/nova/instances/instance-xxxxxxxxxx/disk), führen Sie die folgenden Schritte aus:
Suspendieren Sie die Instanz mit dem Befehl
virsh.Verbinden Sie das qemu-nbd Gerät mit der Festplatte.
Montieren Sie das qemu-nbd Gerät.
Demontieren Sie das Gerät nach der Prüfung.
Trennen Sie das qemu-nbd Gerät.
Nimm die Instanz wieder auf.
Wenn Sie die letzten drei Schritte nicht befolgen, kann OpenStack Compute die Instanz nicht mehr verwalten. Es reagiert nicht auf Befehle von OpenStack Compute und wird als heruntergefahren markiert.
Sobald Sie die Festplattendatei gemountet haben, sollten Sie darauf zugreifen und sie wie eine Sammlung von normalen Verzeichnissen mit Dateien und einer Verzeichnisstruktur behandeln können. Wir empfehlen jedoch nicht, Dateien zu bearbeiten oder zu berühren, da dies den Begriff :Zugriffskontrolllisten (ACLs) <Zugriffskontrollliste (ACL)> ändern könnte, mit dem bestimmt wird, welche Konten welche Operationen an Dateien und Verzeichnissen durchführen können. Das Ändern von ACLs kann dazu führen, dass die Instanz nicht mehr bootfähig ist, wenn sie es nicht bereits ist.
Suspendieren Sie die Instanz mit dem Befehl virsh unter Beachtung der internen ID:
# virsh list Id Name State ---------------------------------- 1 instance-00000981 running 2 instance-000009f5 running 30 instance-0000274a running # virsh suspend 30 Domain 30 suspended
Finden Sie die ID für jede Instanz, indem Sie die Server-IDs mit dem folgenden Befehl auflisten:
# openstack server list +--------------------------------------+-------+---------+-----------------------------+------------+ | ID | Name | Status | Networks | Image Name | +--------------------------------------+-------+---------+-----------------------------+------------+ | 2da14c5c-de6d-407d-a7d2-2dd0862b9967 | try3 | ACTIVE | finance-internal=10.10.0.4 | | | 223f4860-722a-44a0-bac7-f73f58beec7b | try2 | ACTIVE | finance-internal=10.10.0.13 | | +--------------------------------------+-------+---------+-----------------------------+------------+
Verbinden Sie das qemu-nbd Gerät mit der Festplatte:
# cd /var/lib/nova/instances/instance-0000274a # ls -lh total 33M -rw-rw---- 1 libvirt-qemu kvm 6.3K Oct 15 11:31 console.log -rw-r--r-- 1 libvirt-qemu kvm 33M Oct 15 22:06 disk -rw-r--r-- 1 libvirt-qemu kvm 384K Oct 15 22:06 disk.local -rw-rw-r-- 1 nova nova 1.7K Oct 15 11:30 libvirt.xml # qemu-nbd -c /dev/nbd0 `pwd`/disk
Montieren Sie das qemu-nbd Gerät.
Das qemu-nbd-Gerät versucht, die verschiedenen Partitionen der Instanzplatte als separate Geräte zu exportieren. Wenn vda beispielsweise die Festplatte und vda1 die Root-Partition ist, exportiert qemu-nbd die Vorrichtung als
/dev/nbd0und/dev/nbd0p1:# mount /dev/nbd0p1 /mnt/
Sie können nun auf den Inhalt von
/mntzugreifen, der der ersten Partition der Festplatte der Instanz entspricht.Um die sekundäre oder ephemere Festplatte zu untersuchen, verwenden Sie einen alternativen Mount-Punkt, wenn Sie möchten, dass sowohl primäre als auch sekundäre Laufwerke gleichzeitig montiert werden:
# umount /mnt # qemu-nbd -c /dev/nbd1 `pwd`/disk.local # mount /dev/nbd1 /mnt/ # ls -lh /mnt/ total 76K lrwxrwxrwx. 1 root root 7 Oct 15 00:44 bin -> usr/bin dr-xr-xr-x. 4 root root 4.0K Oct 15 01:07 boot drwxr-xr-x. 2 root root 4.0K Oct 15 00:42 dev drwxr-xr-x. 70 root root 4.0K Oct 15 11:31 etc drwxr-xr-x. 3 root root 4.0K Oct 15 01:07 home lrwxrwxrwx. 1 root root 7 Oct 15 00:44 lib -> usr/lib lrwxrwxrwx. 1 root root 9 Oct 15 00:44 lib64 -> usr/lib64 drwx------. 2 root root 16K Oct 15 00:42 lost+found drwxr-xr-x. 2 root root 4.0K Feb 3 2012 media drwxr-xr-x. 2 root root 4.0K Feb 3 2012 mnt drwxr-xr-x. 2 root root 4.0K Feb 3 2012 opt drwxr-xr-x. 2 root root 4.0K Oct 15 00:42 proc dr-xr-x---. 3 root root 4.0K Oct 15 21:56 root drwxr-xr-x. 14 root root 4.0K Oct 15 01:07 run lrwxrwxrwx. 1 root root 8 Oct 15 00:44 sbin -> usr/sbin drwxr-xr-x. 2 root root 4.0K Feb 3 2012 srv drwxr-xr-x. 2 root root 4.0K Oct 15 00:42 sys drwxrwxrwt. 9 root root 4.0K Oct 15 16:29 tmp drwxr-xr-x. 13 root root 4.0K Oct 15 00:44 usr drwxr-xr-x. 17 root root 4.0K Oct 15 00:44 var
Nachdem Sie die Inspektion abgeschlossen haben, entfernen Sie den Mount-Punkt und geben Sie das qemu-nbd-Gerät frei:
# umount /mnt # qemu-nbd -d /dev/nbd0 /dev/nbd0 disconnected
Nimm die Instanz mit virsh wieder auf:
# virsh list Id Name State ---------------------------------- 1 instance-00000981 running 2 instance-000009f5 running 30 instance-0000274a paused # virsh resume 30 Domain 30 resumed
Verwaltung von Floating IP-Adressen zwischen Instanzen¶
In einer elastischen Cloud-Umgebung mit dem Netzwerk „Public_AGILE“ verfügt jede Instanz über eine öffentlich zugängliche IPv4 & IPv6-Adresse. Es unterstützt nicht das Konzept der OpenStack Floating IP-Adressen, die leicht angehängt, entfernt und zwischen Instanzen übertragen werden können. Es gibt jedoch einen Workaround mit Neutronen-Ports, die die IPv4 & IPv6-Adresse enthalten.
Einen Port erstellen, der wiederverwendet werden kann
Erstellen Sie einen Port im
Public_AGILENetzwerk:$ openstack port create port1 --network Public_AGILE Created a new port: +-----------------------+------------------------------------------------------+ | Field | Value | +-----------------------+------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | None | | binding_profile | None | | binding_vif_details | None | | binding_vif_type | None | | binding_vnic_type | normal | | created_at | 2017-02-26T14:23:18Z | | description | | | device_id | | | device_owner | | | dns_assignment | None | | dns_name | None | | extra_dhcp_opts | | | fixed_ips | ip_address='96.118.182.106', | | | subnet_id='4279c70a-7218-4c7e-94e5-7bd4c045644e' | | | ip_address='2001:558:fc0b:100:f816:3eff:fefb:45fb', | | | subnet_id='11d8087b-6288-4129-95ff-42c3df0c1df0' | | id | 3871bf29-e963-4701-a7dd-8888dbaab375 | | ip_address | None | | mac_address | fa:16:3e:e2:09:e0 | | name | port1 | | network_id | f41bd921-3a59-49c4-aa95-c2e4496a4b56 | | option_name | None | | option_value | None | | port_security_enabled | True | | project_id | 52f0574689f14c8a99e7ca22c4eb572 | | qos_policy_id | None | | revision_number | 6 | | security_groups | 20d96891-0055-428a-8fa6-d5aed25f0dc6 | | status | DOWN | | subnet_id | None | | updated_at | 2017-02-26T14:23:19Z | +-----------------------+------------------------------------------------------+
Wenn Sie den voll qualifizierten Domainnamen (FQDN) kennen, der der IP-Adresse zugewiesen wird, weisen Sie den Port mit dem gleichen Namen zu:
$ openstack port create "example-fqdn-01.sys.example.com" --network Public_AGILE Created a new port: +-----------------------+------------------------------------------------------+ | Field | Value | +-----------------------+------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | None | | binding_profile | None | | binding_vif_details | None | | binding_vif_type | None | | binding_vnic_type | normal | | created_at | 2017-02-26T14:24:16Z | | description | | | device_id | | | device_owner | | | dns_assignment | None | | dns_name | None | | extra_dhcp_opts | | | fixed_ips | ip_address='96.118.182.107', | | | subnet_id='4279c70a-7218-4c7e-94e5-7bd4c045644e' | | | ip_address='2001:558:fc0b:100:f816:3eff:fefb:65fc', | | | subnet_id='11d8087b-6288-4129-95ff-42c3df0c1df0' | | id | 731c3b28-3753-4e63-bae3-b58a52d6ccca | | ip_address | None | | mac_address | fa:16:3e:fb:65:fc | | name | example-fqdn-01.sys.example.com | | network_id | f41bd921-3a59-49c4-aa95-c2e4496a4b56 | | option_name | None | | option_value | None | | port_security_enabled | True | | project_id | 52f0574689f14c8a99e7ca22c4eb5720 | | qos_policy_id | None | | revision_number | 6 | | security_groups | 20d96891-0055-428a-8fa6-d5aed25f0dc6 | | status | DOWN | | subnet_id | None | | updated_at | 2017-02-26T14:24:17Z | +-----------------------+------------------------------------------------------+
Verwenden Sie den Port beim Erstellen einer Instanz:
$ openstack server create --flavor m1.medium --image ubuntu.qcow2 \ --key-name team_key --nic port-id=PORT_ID \ "example-fqdn-01.sys.example.com"
Vergewissern Sie sich, dass die Instanz die richtige IP-Adresse hat:
+--------------------------------------+----------------------------------------------------------+ | Field | Value | +--------------------------------------+----------------------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-SRV-ATTR:host | os_compute-1 | | OS-EXT-SRV-ATTR:hypervisor_hostname | os_compute.ece.example.com | | OS-EXT-SRV-ATTR:instance_name | instance-00012b82 | | OS-EXT-STS:power_state | Running | | OS-EXT-STS:task_state | None | | OS-EXT-STS:vm_state | active | | OS-SRV-USG:launched_at | 2016-11-30T08:55:27.000000 | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | public=172.24.4.236 | | config_drive | | | created | 2016-11-30T08:55:14Z | | flavor | m1.medium (103) | | hostId | aca973d5b7981faaf8c713a0130713bbc1e64151be65c8dfb53039f7 | | id | f91bd761-6407-46a6-b5fd-11a8a46e4983 | | image | Example Cloud Ubuntu 14.04 x86_64 v2.5 (fb49d7e1-273b-...| | key_name | team_key | | name | example-fqdn-01.sys.example.com | | os-extended-volumes:volumes_attached | [] | | progress | 0 | | project_id | 2daf82a578e9437cab396c888ff0ca57 | | properties | | | security_groups | [{u'name': u'default'}] | | status | ACTIVE | | updated | 2016-11-30T08:55:27Z | | user_id | 8cbea24666ae49bbb8c1641f9b12d2d2 | +--------------------------------------+----------------------------------------------------------+
Überprüfen Sie die Portverbindung mit dem Dienstprogramm netcat:
$ nc -v -w 2 96.118.182.107 22 Ncat: Version 7.00 ( https://nmap.org/ncat ) Ncat: Connected to 96.118.182.107:22. SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.6
Einen Port von einer Instanz trennen
Suchen Sie den Port, der der Instanz entspricht. Zum Beispiel:
$ openstack port list | grep -B1 96.118.182.107 | 731c3b28-3753-4e63-bae3-b58a52d6ccca | example-fqdn-01.sys.example.com | fa:16:3e:fb:65:fc | ip_address='96.118.182.107', subnet_id='4279c70a-7218-4c7e-94e5-7bd4c045644e' |
Führen Sie den Befehl openstack port set aus, um den Port aus der Instanz zu entfernen:
$ openstack port set 731c3b28-3753-4e63-bae3-b58a52d6ccca \ --device "" --device-owner "" --no-binding-profile
Löschen Sie die Instanz und erstellen Sie eine neue Instanz mit der Option
--nic port-id.
Abrufen einer IP-Adresse, wenn eine Instanz gelöscht wird, bevor ein Port abgetrennt wird
Die folgende Vorgehensweise ist ein möglicher Workaround, um eine IP-Adresse abzurufen, wenn eine Instanz gelöscht wurde und der Port noch angeschlossen ist:
Starten Sie mehrere Neutron-Ports:
$ for i in {0..10}; do openstack port create --network Public_AGILE \ ip-recovery; done
Überprüfen Sie die Ports auf die verlorene IP-Adresse und aktualisieren Sie den Namen:
$ openstack port set 731c3b28-3753-4e63-bae3-b58a52d6ccca \ --name "don't delete"
Löschen Sie die nicht benötigten Ports:
$ for port in $(openstack port list | grep -i ip-recovery | \ awk '{print $2}'); do openstack port delete $port; done
Wenn Sie die verlorene IP-Adresse immer noch nicht finden, wiederholen Sie diese Schritte erneut.
Datenträger¶
Wenn die betroffenen Instanzen auch angehängte Volumes hatten, erzeugen Sie zunächst eine Liste von Instanz- und Volume UUIDs:
mysql> select nova.instances.uuid as instance_uuid,
cinder.volumes.id as volume_uuid, cinder.volumes.status,
cinder.volumes.attach_status, cinder.volumes.mountpoint,
cinder.volumes.display_name from cinder.volumes
inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid
where nova.instances.host = 'c01.example.com';
Sie sollten ein ähnliches Ergebnis wie das folgende sehen:
+--------------+------------+-------+--------------+-----------+--------------+
|instance_uuid |volume_uuid |status |attach_status |mountpoint | display_name |
+--------------+------------+-------+--------------+-----------+--------------+
|9b969a05 |1f0fbf36 |in-use |attached |/dev/vdc | test |
+--------------+------------+-------+--------------+-----------+--------------+
1 row in set (0.00 sec)
Als nächstes müssen Sie die Volumes manuell trennen und wieder anhängen, wobei X der richtige Einhängepunkt ist:
# openstack server remove volume <instance_uuid> <volume_uuid>
# openstack server add volume <instance_uuid> <volume_uuid> --device /dev/vdX
Stellen Sie sicher, dass die Instanz erfolgreich gebootet hat und sich auf einem Anmeldebildschirm befindet, bevor Sie die oben genannten Schritte ausführen.
Totaler Ausfall des Compute-Knotens¶
Compute-Knoten können genauso ausfallen wie ein Cloud-Controller. Ein Mainboard-Ausfall oder eine andere Art von Hardware-Ausfall kann dazu führen, dass ein ganzer Compute-Knoten offline geht. In diesem Fall sind alle Instanzen, die auf diesem Compute-Knoten ausgeführt werden, nicht verfügbar. Genau wie bei einem Ausfall eines Cloud-Controllers, wenn Ihre Infrastrukturüberwachung keinen ausgefallenen Compute-Knoten erkennt, werden Ihre Benutzer Sie wegen ihrer verlorenen Instanzen benachrichtigen.
Wenn ein Compute Node ausfällt und für einige Stunden (oder überhaupt nicht) repariert wird, können Sie alle Instanzen, die auf dem ausgefallenen Knoten gehostet werden, neu starten, wenn Sie gemeinsamen Speicher für /var/lib/nova/instances verwenden.
Erzeugen Sie dazu eine Liste von Instanz-UUIDs, die auf dem ausgefallenen Knoten gehostet werden, indem Sie die folgende Abfrage auf der nova-Datenbank ausführen:
mysql> select uuid from instances
where host = 'c01.example.com' and deleted = 0;
Aktualisieren Sie anschließend die nova-Datenbank, um anzuzeigen, dass alle Instanzen, die bisher auf c01.example.com gehostet wurden, nun auf c02.example.com gehostet werden:
mysql> update instances set host = 'c02.example.com'
where host = 'c01.example.com' and deleted = 0;
Wenn Sie das Plug-in für den Netzwerkdienst ML2 verwenden, aktualisieren Sie die Datenbank des Netzwerkdienstes, um anzuzeigen, dass alle Ports, die früher auf c01.example.com gehostet wurden, nun auf c02.example.com gehostet werden:
mysql> update ml2_port_bindings set host = 'c02.example.com'
where host = 'c01.example.com';
mysql> update ml2_port_binding_levels set host = 'c02.example.com'
where host = 'c01.example.com';
Verwenden Sie anschließend den Befehl openstack, um alle Instanzen, die sich auf c01.example.com befanden, neu zu starten und gleichzeitig ihre XML-Dateien zu generieren:
# openstack server reboot --hard <server>
Schließlich können Sie Volumes mit der gleichen Methode neu anhängen, die im Abschnitt Datenträger beschrieben ist.
/var/lib/nova/instances¶
Es ist erwähnenswert, dieses Verzeichnis im Zusammenhang mit fehlgeschlagenen Compute-Knoten zu erwähnen. Dieses Verzeichnis enthält die dateibasierten libvirt KVM-Disk Images für die Instanzen, die auf diesem Compute-Knoten gehostet werden. Wenn Sie Ihre Cloud nicht in einer Shared Storage-Umgebung betreiben, ist dieses Verzeichnis für alle Compute-Knoten eindeutig.
/var/lib/nova/instances enthält zwei Arten von Verzeichnissen.
Das erste ist das Verzeichnis _base. Dies enthält alle zwischengespeicherten Basisabbilder von Glance für jedes einzelne Abbild, das auf diesem Compute-Knoten gestartet wurde. Dateien mit der Endung _20 (oder einer anderen Nummer) sind die ephemeren Basisabbilder.
Die anderen Verzeichnisse tragen den Titel Instance-xxxxxxxxxxxxxx. Diese Verzeichnisse entsprechen den Instanzen, die auf diesem Compute-Knoten ausgeführt werden. Die darin enthaltenen Dateien beziehen sich auf eine der Dateien im Verzeichnis _base. Es handelt sich im Wesentlichen um differentiell basierte Dateien, die nur die Änderungen enthalten, die aus dem ursprünglichen _base Verzeichnis vorgenommen wurden.
Alle Dateien und Verzeichnisse in /var/lib/nova/instances sind eindeutig benannt. Die Dateien in _base sind eindeutig für das glance image benannt, auf dem sie basieren, und die Verzeichnisnamen instance-xxxxxxxxxxxx sind eindeutig für diese spezielle Instanz benannt. Wenn Sie beispielsweise alle Daten von /var/lib/nova/instances auf einem Compute-Knoten in einen anderen kopieren, überschreiben Sie keine Dateien und richten keinen Schaden an Abbildern mit demselben eindeutigen Namen an, da es sich im Wesentlichen um die gleiche Datei handelt.
Obwohl diese Methode nicht dokumentiert oder unterstützt wird, können Sie sie verwenden, wenn Ihr Compute-Knoten permanent offline ist, aber Sie lokal gespeicherte Instanzen haben.
