Bekannte Probleme bei Compute

Details

ClamAV-Signatur markierte legitime Binärdateien als Viren aufgrund einer fehlerhaften Signaturdatenbank (Virusdefinition 26931). Dieses Problem hat dazu geführt, dass ClamAV Oracle Cloud Agent und seine Plug-ins als Viren identifiziert hat. Standardmäßig stellt ClamAV infizierte Dateien nicht unter Quarantäne. Daher funktionieren trotz der falschen Erkennung das Mittel und seine Plugins weiterhin normal. Selbst wenn eine Quarantäneaktion für eine Instanz durchgeführt wurde, bleiben der Agent und die Plug-ins unberührt, und Funktionen wie Updater und Heartbeat funktionieren wie erwartet. Bei einem Neustart des Agent oder der Instanz wird die Funktionalität jedoch unterbrochen.

Workaround

Wenn Ihre Instanz betroffen ist, finden Sie weitere Informationen unter Oracle Cloud Agent-Software installieren, um ein neues Package von Oracle Cloud Agent zu installieren.

Details

Eine vorhandene Einschränkung bei virtuellen Netzwerkanhängen begrenzt die gesamte Hostnetzwerkbandbreite auf 60 Gbit/s bei BM.Standard.E5.192.

Workaround

Kein Workaround vorhanden. Wir arbeiten an einem Software-Fix, der sich bei der Bereitstellung nicht auf Live-Netzwerk-Workloads auswirkt.

Details

Nachdem Sie eine Compute-Instanz erstellt haben, können Sie Confidential Computing für diese Instanz nicht zu einem späteren Zeitpunkt aktivieren oder deaktivieren.

Workaround

Eine Lösung für dieses Problem ist in Arbeit.

Details

Confidential Computing wird auf Oracle Linux 9 nicht unterstützt.

Workaround

Eine Lösung für dieses Problem ist in Arbeit.

Details

Bei AMD-Systemen einer älteren Generation (E2/E3 mit AMD Rome-Prozessoren) kann ein Gast, der Secure Encrypted Virtualization-(SEV-)Speicherverschlüsselung (standardmäßig nicht aktiviert) mit mehr als 350 GB Arbeitsspeicher verwendet, beim Booten/Herunterfahren des Gasts zu einer CPU-Soft-Lockup-Warnung auf Host/Hypervisor führen. Das liegt daran, dass die Zeit, die zum Löschen des gepinnten Arbeitsspeichers benötigt wird, proportional zur Speichermenge ist und bei größeren Speichermengen über 350 GB die CPU-Zeit übermäßig hoch ist und zu einer Warnung führt. Nachdem der Arbeitsspeicher geleert wurde, kehrt der Hypervisor in den normalen Betrieb zurück.

Neuere Systeme wie E4 (basierend auf AMD Milan-Prozessoren) verfügen über Hardwareunterstützung, die die Zeit für das Leeren des Arbeitsspeichers minimiert, sodass kein Soft Hang für die CPU auftritt.

Workaround

Wenn Sie einen SEV-fähigen Gast mit mehr als 350 GB Arbeitsspeicher benötigen, erstellen Sie diesen auf einem E4-System (basierend auf AMD Milan-Prozessoren). Begrenzen Sie auf Systemen mit AMD Rome-Prozessoren (E2/E3) den Arbeitsspeicher auf weniger als 350 GB, wenn Sie die SEV-Speicherverschlüsselung verwenden.

Details

Für die folgenden Compute-Ausprägungen werden mehrere Namen für dieselbe Ausprägung verwendet.

• BM.GPU.A10.4: Der Name wird sowohl als BM.GPU.A10.4- als auch als BM.GPU.GU1.4-Name angezeigt.
• BM.GPU.A100-v2.8: Der Name wird sowohl als BM.GPU.A100-v2.8 als auch als BM.GPU.GM4.8 angezeigt.
• VM.GPU.A10.1: Der Name wird sowohl als VM.GPU.A10.1- als auch als VM.GPU.GU1.1-Name angezeigt.
• VM.GPU.A10.2: Der Name wird sowohl als VM.GPU.A10.2- als auch als VM.GPU.GU1.2-Name angezeigt.

Workaround

Ignorieren Sie die verschiedenen Namen. Die zugrunde liegende Hardware ist für jede Ausprägung dieselbe.

Details

Wenn Sie versuchen, eine Verbindung zu einer Instanz in Oracle Cloud Infrastructure mit einem Client herzustellen, auf dem macOS Ventura (Version 13) ausgeführt wird, oder mit OpenSSH 9.0, treten möglicherweise Verbindungsprobleme auf, die zu folgenden Fehlern führen:

Unable to negotiate with 192.0.2.181 port 22: no matching host key type found. Their offer: ssh-rsa
kex_exchange_identification: Connection closed by remote host

Workaround

Fügen Sie der Datei ~/.ssh/config Folgendes hinzu:

Host *
  PubkeyAcceptedKeyTypes +ssh-rsa
  HostkeyAlgorithms +ssh-rsa

Details

Instanzen, die das Plattformimage vom September 2022 für CentOS 7 (Imagename CentOS-7-2022.09.20-0) ausführen, verlieren nach 24 Stunden die Verbindung zu über iSCSI angehängten Boot-Volumes. Das Problem tritt auf, weil die Instanz ihr Lease nach 24 Stunden verliert.

Workaround

Wir empfehlen, alle vorhandenen Instanzen, die dieses Image verwenden, zu beenden (löschen) und die Instanzen mit einem anderen CentOS 7-Plattformimage neu zu erstellen.

Wenn Sie vorhandene Instanzen, die das Plattformimage vom September 2022 für CentOS 7 verwenden, nicht beenden können, können Sie ein neues 24-Stunden-Lease durch Neustarten der Instanz anfordern.

Details

Dieses Problem betrifft Bare-Metal-Instanzen, die Ausprägungen der vorherigen Generation verwenden (für dieses bekannte Problem: Ausprägungen mit einem Enddatum der Bestellbarkeit vor Oktober 2022) und die die Windows Server 2016 Datacenter-Edition ausführen.

Wenn Sie den Virtual Switch Manager von Hyper-V öffnen und versuchen, einen neuen externen virtuellen Switch (vSwitch) zu erstellen, wird eine Fehlermeldung wie die Folgende angezeigt: "Fehler bei der Anwendung von Virtual Switch Properties-Änderungen: Fehler beim Hinzufügen virtueller Ethernet-Switchverbindungen."

Dieser Fehler tritt auf, weil ein Broadcom-Treiber, der nach dem Ausführen von Microsoft Windows Update installiert wurde, nicht von Oracle zertifiziert wurde.

Workaround

Broadcom-Treiberversion 20.8.24.0 ist von Oracle zertifiziert. Installieren Sie Version 20.8.24.0.

Details

Wenn Sie Container auf einer Compute-Instanz ausführen, die Ubuntu 20.04, Kernel-Version linux-oracle-5.13 5.13.0-1033.39~20.04.1 verwendet, tritt eine Kernel Panic auf. Die Instanz stürzt ab und es ist kein Zugriff darauf möglich. Weitere Informationen finden Sie unter Erstellung eines Docker-Containers führt zu Kernel Oops auf Linux-aws 5.13.0.1028.31~20.04.22.

Workaround

Aktualisieren Sie den Kernel auf eine höhere Version, indem Sie die folgenden Befehle ausführen:

sudo apt-get update

sudo apt-get upgrade -y linux-image-oracle

Details

VM-Instanzen mit flexibler E3/E4-Ausprägung, die vor dem 5. April 2021 erstellt wurden, können nicht gestartet werden, wenn der Arbeitsspeicher auf mehr als 1.010 GB skaliert wurde. In diesem Fall wird die Fehlermeldung "Start nicht erfolgreich" angezeigt.

Workaround 1

Verringern Sie die Arbeitsspeichergröße auf weniger als 1.010 GB.

Workaround 2

Erstellen Sie die Instanz erneut, und skalieren Sie dann die Arbeitsspeichergröße der Instanz auf bis zu 1.024 GB.

Details

Oracle Autonomous Linux wird für Compute-Instanzen vom Typ Immer kostenlos nicht unterstützt. In der Konsole wird Oracle Autonomous Linux jedoch in der Liste der unterstützten Images für Ausprägungen vom Typ Immer kostenlos angezeigt.

Workaround

Eine Lösung für dieses Problem ist in Arbeit.

Details

Wenn in der Region US East (Ashburn) Oracle Linux-Instanzen nach dem Provisioning zum ersten Mal gestartet werden, funktioniert DNS möglicherweise nicht wie erwartet, und das Feld search in der Datei /etc/resolv.conf ist möglicherweise unvollständig.

Workaround

Starten Sie die Instanz neu, oder warten Sie auf die nächste Verlängerung der DHCP-Lease. Durch Verlängerung der DHCP-Lease wird das Problem automatisch behoben. Die standardmäßige DHCP-Lease-Zeit beträgt 24 Stunden, variiert jedoch je nach Netzwerkeinstellungen.

Details

Wenn Sie eine abgeschirmte Instanz mit Linux 7.x erstellen und die Instanz dann neu starten, können sich die PCR-Werte ändern, sodass das rote Schildsymbol angezeigt wird.

Workaround

Einige PCR-Werte ändern sich zur Laufzeit. Diese Änderung entspricht den Erwartungen. Als Workaround können Sie die goldenen Messungen zurücksetzen.

Details

Bei Bare-Metal-Instanzen, die die Ausprägung BM.Standard.A1.160 verwenden, ergibt sich eine verringerte Netzwerkperformance für Workloads, die auf CPUs mit Socket 1 ausgeführt werden.

Workaround

Binden Sie Anwendungen, die für die Paketverarbeitung über das Netzwerk zuständig sind, an CPUs mit Socket 0.

Details

Wenn Sie eine Compute-Instanz unter Windows in einem privaten Subnetz mit einem angehängten Servicegateway bereitstellen, geben die Oracle Cloud Agent-Plug-ins möglicherweise keine Metriken aus.

Workaround

Befolgen Sie die Schritte im Artikel über bekannte Probleme von Microsoft: Konnektivitätsprobleme, wenn das globale Root-Zertifikat DigiCert G2 nicht installiert wurde.

Details

Bei Instanzen, die die VM.Standard.A1.Flex-Ausprägung mit hardwaregestütztem Networking (SR-IOV) verwenden, können Performanceprobleme und in seltenen Fällen Datenbeschädigungen auftreten. Um dies zu verhindern, werden Plattformimages für OCI Ampere A1 Compute (aarch64) so konfiguriert, dass sie ausschließlich paravirtualisiertes Networking verwenden. Wenn Sie eine Instanz mit einem Plattformimage erstellen und hardwaregestütztes Networking angeben, verläuft der Start nicht erfolgreich, und eine Meldung wie Failed to validate instance launch options (Instanz-Startoptionen konnten nicht erstellt werden) wird ausgegeben.

Bei benutzerdefinierten Images, die mit OCI Ampere A1 Compute kompatibel sind, wird der Start erfolgreich ausgeführt. Es wird jedoch empfohlen, kein hardwaregestützes Networking auszuwählen, um potenzielle Probleme mit Performance und Datenbeschädigung zu vermeiden.

Workaround

Wenn Sie eine VM.Standard.A1.Flex-Instanz mit einem Plattformimage erstellen, kann Oracle den empfohlenen Starttyp für das Networking auswählen. Verwenden Sie bei benutzerdefinierten Images kein hardwaregestütztes (SR-IOV) Networking.

Details

Instanzen mit VM.Standard.A1. Flex-Ausprägungen mit hardwaregestützten (SR-IOV-)Netzwerken und einer großen Anzahl von Kernen haben die Performance gegenüber der Verwendung von paravirtualisierten Netzwerken verbessert. SR-IOV-Networking begrenzt jedoch die Anzahl der Kerne auf 76 und die Arbeitsspeichermenge auf 456 GB.

Wenn Sie versuchen, eine Instanz zu erstellen, die einen dieser Limits überschreitet, tritt ein Fehler auf, der angibt, dass keine ausreichende Kapazität zum Erstellen der Instanz vorhanden ist.

Workaround

Eine Lösung für dieses Problem ist in Arbeit.

Details

Wenn Sie mit Terraform eine Intel- oder AMD-Compute-Instanz mit einem Linux-Plattformimage erstellen, verläuft der Vorgang möglicherweise nicht erfolgreich, mit dem Fehlercode InvalidParameter und einer Meldung wie Shape <shape_name> is not valid for image <image_OCID>.

Dies geschieht, wenn Terraform das neueste Image basierend auf dem Image display_name identifiziert. Images für Intel- und AMD-Ausprägungen (Prozessorarchitektur x86) haben ähnliche Namen wie Images für Arm-basierte Ausprägungen (Prozessorarchitektur aarch64), die Images sind jedoch nicht über mehrere Prozessorarchitekturen hinweg kompatibel. Wenn das neueste Image ein aarch64-Image ist, wählt Terraform ein aarch64-Image für eine x86-Ausprägung aus, was dazu führt, dass der Vorgang nicht erfolgreich verläuft.

Workaround

Ändern Sie die folgenden Terraform-Dateien:

• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/global/global.datasources.tf
• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/pd/pd.datasources.tf
• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/nonpd/nonpd.datasources.tf
• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/globalDR/globalDR.datasources.tf
• /home/opc/JDERefArch_InfraProvisioning/TerraformScripts/pdDR/pdDR.datasources.tf

Aktualisieren Sie in den Dateien den regulären Ausdruck, der das Image identifiziert, um alle Images für Arm-basierte Ausprägungen herauszufiltern. Die Namen von Images für Arm-basierte Ausprägungen enthalten „aarch“.

Beispiel: Führen Sie für Oracle Linux 8-Images das folgende Update durch:

• Aktueller regulärer Ausdruck: values = ["^.*Oracle-Linux-8[.]*[\\d]*-[^G].*$"]
• Aktualisierter regulärer Ausdruck: values = ["^.*Oracle-Linux-8[.][0-9]*-[\\d]{4}.[\\d]{2}.[\\d]{2}-[\\d]*$"]

Details

Instanzen, die das Oracle Linux Cloud Developer-Image verwenden, können nicht vom OS Management-Service verwaltet werden.

Workaround

Installieren Sie den OS Management-Service-Agent (osms-agent) nicht auf Oracle Linux Cloud Developer-Instanzen.

Details

Wenn Sie versuchen, ein benutzerdefiniertes Image aus einem Objektspeicher-Bucket zu importieren oder zu exportieren, kann ein Fehler wie der Folgende auftreten:

Invalid bucketName: Specified namespace or bucket to export image does not exist (Ungültiger bucketName: Angegebener Namespace oder Bucket zum Exportieren eines Images existiert nicht)

Dieser Fehler tritt für föderierte Benutzer und für Benutzer auf, die sich mit Instanz-Principals authentifizieren, die mit einer dynamischen Gruppe verknüpft sind.

Workaround

Erstellen Sie eine vorab authentifizierte Anforderung, und verwenden Sie diese dann, um das Image zu importieren oder zu exportieren. Mit vorab authentifizierten Anforderungen können Nutzer auf einen Bucket oder ein Objekt zugreifen, ohne eigene Zugangsdaten zu besitzen. Eine ausführliche Anleitung zum Erstellen und Verwenden von vorab authentifizierten Anforderungen finden Sie unter Vorab authentifizierte Anforderungen verwenden und Vorab authentifizierte Anforderungen.

Details

Wenn Sie versuchen, eine Instanz aus einem Boot-Volume-Backup in der Konsole zu erstellen, kann ein Fehler wie der Folgende auftreten:

"Beim Laden des Quellimages zum Erstellen einer Instanz ist ein Fehler aufgetreten. Sie haben möglicherweise keine Berechtigung zum Zugriff auf dieses Image, oder es befindet sich in einer anderen Region. Wenn sich das Image in einer anderen Region befindet, können Sie Ihre Instanz trotzdem starten."

Dieser Fehler kann auftreten, wenn das Compartment mit den gelöschten Imagemetadaten, die für das Boot-Volume-Backup verwendet werden, ebenfalls gelöscht wurde.

Workaround

Wenn das Compartment gelöscht wurde, erstellen Sie die Instanz mit der CLI. Informationen zur Verwendung der CLI finden Sie unter Befehlszeilenschnittstelle (CLI).

Um eine Instanz über ein Boot-Volume mit der CLI zu erstellen, öffnen Sie eine Eingabeaufforderung, und führen Sie den Befehl launch aus. Um eine Instanz mit einem Image oder einem Boot-Volume zu starten, nehmen Sie den Parameter --source-details auf.

oci compute instance launch --availability-domain <availability_domain> --compartment-id, -c <compartment_ocid> --shape <shape> --subnet-id <subnet_id> --source-details <file://path/to/file>

Details

Eine Instanz kann nicht mit Terraform aus einer Kapazitätsreservierung entfernt werden.

Lösungen

Verwenden Sie eine der folgenden Lösungen:

• Verwenden Sie die Konsole, die CLI oder das SDK, um die Instanz aus der Kapazitätsreservierung zu entfernen.
• Mit Terraform können Sie eine Instanz entfernen, indem Sie capacity_reservation_id wie im folgenden Terraform-Skriptbeispiel auf ein Leerzeichen setzen:

  capacity_reservation_id = " "

Details

Wenn Sie in einer Kapazitätsreservierung mehr als 50 Kapazitätskonfigurationen erstellen, tritt ein interner Fehler auf. Nach Auftreten des Fehlers können keine Instanzen gegen die Kapazitätsreservierung gestartet werden.

Workaround

Um dieses Problem zu vermeiden, fügen Sie Ihrer Kapazitätsreservierung nicht mehr als 50 Kapazitätskonfigurationen hinzu.

Details

Die Servicelimitnummern für <shape>-core-reserved-count sind nicht korrekt. Die Zahl in der Spalte Servicelimit kann 1.000.000.000 oder N/V lauten. Die Zahl in der Spalte Verfügbar kann 1.000.000.000 minus der Zahl in der Spalte Verwendung oder N/V sein. Der Wert 1.000.000.000 stellt einen Höchstwert dar und kann variieren.

Workaround

Genaue Servicelimits finden Sie unter Reservierungen der Compute-Kapazität.

Details

Wenn Sie eine Erhöhung des Servicelimits beantragen, enthält das Menü Servicekategorie keine Kategorie für Kapazitätsreservierungen.

Workaround

Gehen Sie im Formular Aktualisierungen der Servicelimits beantragen wie folgt vor:

• Wählen Sie unter Servicekategorie die Option Andere aus.
• Wählen Sie für Ressource die Option Andere Limits aus.
• Geben Sie im Feld Grund für Anforderung das spezifische Limit ein, das erhöht werden soll.

Details

Wenn Sie versuchen, einen Instanzpool zu erstellen, verläuft die Erstellung nicht erfolgreich, und die Fehlermeldung "Authorization failed or requested resource not found" (Autorisierung war nicht erfolgreich, oder angeforderte Ressource wurde nicht gefunden) wird angezeigt. Dies geschieht, weil Ressourcen, die vom Instanzpool verwendet werden, Standardtags enthalten und der Benutzer keine Berechtigung für den Tag-Namespace hat.

Workaround

Fügen Sie eine Policy-Anweisung hinzu, die der Benutzergruppe des Instanzpools Berechtigungen für den Tag-Namespace Oracle-Tags erteilt:

Allow group InstancePoolUsers to use tag-namespaces in tenancy where target.tag-namespace.name = 'oracle-tags'

Weitere Informationen zu Policys finden Sie unter Verwalten von Compute-Instanzkonfigurationen, Instanzpools und Clusternetzwerken durch Benutzer zulassen. Weitere Informationen zu Standardtags finden Sie unter Automatische Tagstandardwerte.

Details

Wenn Sie versuchen, eine Instanz zu erstellen, verläuft der Instanzstart nicht erfolgreich, und der Fehlercode InternalError und eine Meldung wie Out of host capacity (Fehlende Hostkapazität) werden ausgegeben. Ursache ist die fehlende physische Infrastrukturkapazität für die Ausprägung in der angeforderten Faultdomain und Availability-Domain.

Workaround

Kapazität ist in der Regel bald für die meisten Ausprägungen verfügbar. So umgehen Sie dieses Problem:

• Um zu bestimmen, ob Kapazität für eine bestimmte Ausprägung verfügbar ist, bevor Sie eine Instanz erstellen, verwenden Sie den Vorgang CreateComputeCapacityReport.
• Wenn Sie eine Ausprägung der vorherigen Generation verwenden, erstellen Sie die Instanz stattdessen mit einer Ausprägung der aktuellen Generation. Für Ausprägungen der vorherigen Generation sind die Kapazitäten begrenzt.
• Erstellen Sie die Instanz in einer anderen Availability-Domain.
• Erstellen Sie die Instanz, ohne eine Faultdomain anzugeben.
• Erstellen Sie die Instanz mit einer kleineren Ausprägung oder mit einer Ausprägung in einer anderen Reihe.
• Warten Sie einige Minuten, und versuchen Sie es erneut.

Details

Wenn der Wert für die Verschlüsselung während der Übertragung für ein Image nicht angegeben ist, kann dieser Wert für eine Instanz, die aus dem Image erstellt wird, angegeben werden.

Workaround

Eine Lösung für dieses Problem ist in Arbeit.

Details

Wenn Sie eine Windows Server-Instanz als Domaincontroller verwenden, sind Features, die von Oracle Cloud Agent abhängig sind, nicht verfügbar, wie z.B. der Monitoring-Service und der OS Management-Service. Dies geschieht, weil die von Oracle Cloud Agent unter Windows installierten Services mit virtuellen Accounts ausgeführt werden, virtuelle Accounts jedoch im Geltungsbereich des Domaincontrollers nicht unterstützt werden.

Workaround

1. Deaktivieren Sie den Oracle Cloud Agent-Updater, indem Sie den folgenden PowerShell-Befehl als Administrator ausführen:

   net stop OCAU

   Hinweis
   
   Wenn Sie den Oracle Cloud Agent-Updater deaktivieren, erhält die Instanz in Zukunft keine automatischen Oracle Cloud Agent-Updates mehr. Sie können Oracle Cloud Agent manuell aktualisieren, müssen diesen Workaround jedoch nach der Aktualisierung wiederholen.

2. Aktualisieren Sie für jedes Oracle Cloud Agent-Feature, das Sie verwenden möchten, den laufenden Benutzer für den entsprechenden NT-Service, so dass ein Domainbenutzeraccount verwendet wird.

   Stellen Sie sicher, dass der Domainaccount gemäß der folgenden Tabelle zu den Performance Monitor-Benutzern oder der Administratorgruppe gehört. Verwenden Sie Active Directory Users and Computers, um einen entsprechenden Benutzeraccount aus Ihrer Domain zu finden, und stellen Sie sicher, dass der Benutzer wie in der folgenden Tabelle gezeigt Mitglied der lokalen Zieldomaingruppe ist.

   Oracle Cloud Agent-Funktion	Zielaccounttyp	Lokale Zieldomaingruppe
   Oracle Cloud Agent-NT-Service (einschließlich Plug-in zum Compute-Instanzmonitoring)	Domainserviceaccount oder Benutzeraccount	Performance Monitor-Benutzer
   Compute Instance Run Command-Plug-in	Domainserviceaccount oder Domainbenutzeraccount mit lokalen Administratorberechtigungen	Administratorengruppe
   Oracle Cloud Unified Monitoring Installer Service (Plug-in für das Monitoring benutzerdefinierter Logs)	Domainserviceaccount oder Domainbenutzeraccount mit lokalen Administratorberechtigungen	Administratorengruppe
   BS Managementservice-Agent-Plug-in	Domainserviceaccount oder Domainbenutzeraccount mit lokalen Administratorberechtigungen	Administratorengruppe
   Oracle Cloud Agent-Updater	Domainserviceaccount oder Domainbenutzeraccount mit lokalen Administratorberechtigungen	Administratorengruppe

3. Verwenden Sie services.msc, um den Ausführungsbenutzer des Service auf den Domainbenutzeraccount mit den entsprechenden Domaingruppen zu aktualisieren.

Details

Aufgrund einer Änderung der Verarbeitung von Images durch den Compute-Service sind neu erstellte Boot-Volume-Backups größer als erwartet. In einigen Fällen kann das Boot-Volume-Backup größer als das Boot-Volume selbst sein.

Workaround

Eine Lösung für dieses Problem ist in Arbeit.

Details

Bei Ihrer Compute-Instanz können vorübergehende Fehler bei folgenden Aufgaben auftreten:

• Beim Herstellen einer Verbindung zur Instanz mit SSH
• Beim Ausführen eines DNS-Lookups
• Beim Zugreifen auf den Metadatenservice unter http://169.254.169.254/*

Workaround

Um dieses Problem vorübergehend zu umgehen, führen Sie den folgenden Befehl auf der Instanz aus:

sudo ethtool -G ens3 tx 513 && sudo ethtool -G ens3 tx 512

Details

Wenn Sie zwischen dem 22. März 2019 und dem 9. April 2019 ein yum-Update für Ihre Instanz mit den Oracle Linux 7-yum-Repositorys durchgeführt haben, tritt möglicherweise das Problem auf, dass über iSCSI angehängte Block-Volumes nach dem Neustart der Instanz nicht verfügbar sind.

Workaround

Dieses Problem tritt auf, wenn für die Instanz keine automatische Anmeldung bei den iSCSI-Knoten beim Neustart konfiguriert ist. Um die automatische Anmeldung zu konfigurieren, aktualisieren Sie die Version des Packages iscsi-initiator-utils, indem Sie den folgenden Befehl ausführen:

sudo yum update -y iscsi-initiator-utils-6.2.0.874-10.0.7.el7

Details

Oracle Cloud Infrastructure unterstützt über iSCSI angehängte Remote-Boot- und Block-Volumes für Compute-Instanzen. Diese über iSCSI angehängten Volumes werden vom iscsid-Service verwaltet. In Szenarios, in denen dieser Service aus irgendeinem Grund gestoppt wird, z.B. wenn der Service ausfällt oder ein Systemadministrator den Service versehentlich stoppt, ist es wichtig, dass der iscsid-Service automatisch neu gestartet wird, um die Stabilität der Infrastruktur zu erhöhen.

Workaround

Die Schritte zum Konfigurieren des iscsid-Service für den automatischen Neustart finden Sie unter Linux-iSCSI-Service für den automatischen Neustart aktualisieren.

Details

Wenn Sie für eine VM-Instanz einen Wert für das ipxeScript-Attribut der Instanz angeben, wird die Instanz mit einem iSCSI-Anhang für das Boot-Volume und nicht mit einem paravirtualisierten Anhang gestartet.

Workaround

Eine Lösung für dieses Problem ist in Arbeit.

Details

Bei einer Compute-Instanz kann das System hängen, nachdem Sie den folgenden Befehl ausgeführt haben, um die Firewall erneut zu laden:

firewall-cmd --reload

Wenn Sie die Firewall mit diesem Befehl auf einer laufenden Instanz erneut laden, kann es basierend auf der Reihenfolge, in der die Firewallregeln erneut geladen werden, vorkommen, dass die iSCSI-Verbindung des Boot-Volumes der Instanz verloren geht und abstürzt.

Workaround

Um dieses Problem zu vermeiden, verwenden Sie nicht den Parameter reload für firewall-cmd. Führen Sie stattdessen den Befehl firewall-cmd zweimal aus. Verwenden Sie dabei den Parameter permanent, wenn Sie ihn zum ersten Mal aufrufen, um sicherzustellen, dass die iSCSI-Verbindung nicht verloren geht.

Beispiel:

firewall-cmd --permanent
firewall-cmd

Details

Auf Instanzen, auf denen Windows 2016 ausgeführt wird, wird ein rotes "x" auf dem Netzwerkverbindungssymbol in der Taskleiste angezeigt, obwohl kein Problem mit der Netzwerkkonnektivität der Instanz vorliegt.

Workaround

Wenn Sie den explorer.exe-Prozess wiederverwenden, zeigt das Symbol den richtigen Status an. Allerdings ist dies kein permanenter Fix. Das rote "x" wird erneut angezeigt, wenn Sie die Instanz neu starten.

Details

iSCSId ist im Oktober-2018-Release des Ubuntu 18.04-Plattformimages standardmäßig deaktiviert. Daher kann bei Instanzen, die dieses Betriebssystem verwenden, das System hängen, wenn die iSCSI-Kommunikation kurz unterbrochen wird.

Workaround

Führen Sie den folgenden Befehl aus, um iSCSId auf der Instanz zu aktivieren:

sudo systemctl enable iscsid && sudo systemctl start iscsid

Details

Beim Aufrufen des Vorgangs GetInstance oder ListInstances ist das kmsKeyId-Attribut von InstanceSourceViaImageDetails Null.

Workaround

Rufen Sie den GetBootVolume-Vorgang auf, und rufen Sie den Wert aus dem kmsKeyId-Attribut von BootVolume ab.

Details

Nachdem Sie UFW auf einer Compute-Instanz aktiviert haben, auf der Ubuntu ausgeführt wird, kann die Instanz nicht erfolgreich neu gestartet werden.

Workaround

Verwenden Sie UFW nicht zum Bearbeiten von Firewallregeln. Plattformimages werden mit Firewallregeln vorkonfiguriert, damit Instanzen ausgehende Verbindungen zu den Boot- und Block-Volumes der Instanz herstellen können. Weitere Informationen finden Sie unter Wichtige Firewallregeln. Mit UFW werden diese Regeln möglicherweise entfernt, sodass die Instanz beim Neustart keine Verbindung zu den Boot- und Block-Volumes herstellen kann.

Aktualisieren Sie stattdessen die Datei /etc/iptables/rules.v4, um Firewallregeln zu ändern oder neue Firewallregeln hinzuzufügen. Änderungen an Firewallregeln treten nach einem Neustart in Kraft. Damit die Regeln sofort in Kraft treten, führen Sie den folgenden Befehl aus:

$ sudo su -
# iptables-restore < /etc/iptables/rules.v4

Details

Sie können sich nicht bei einer Instanz anmelden, die aus einem neu erstellten benutzerdefinierten Windows-Image gestartet wurde. Dieses Problem ist auf einen Fehler beim Imagegeneralisierungsprozess zurückzuführen, der aufgrund eines Problems mit Sysprep nach dem Upgrade auf WMF 5.0 auftritt.

Workaround

Führen Sie die unter Sysprep-Fehler nach WMF 5.0-Installation beschriebenen Schritte aus.

Details

Wenn Ubuntu 16 LTS und neuere Releases von Ubuntu importiert werden, kann DHCP die Gatewaykonfiguration nicht abrufen und daher keine Standardroute zum Gateway auf der VNIC einrichten.

Workaround

Konfigurieren Sie die Standardroute nach dem Import statisch. Gehen Sie dazu wie folgt vor:

1. Erstellen Sie das folgende Skript:

   #! /bin/bash -e
   								ROUTER_IP=$(/usr/bin/curl --silent http://169.254.169.254/opc/v1/vnics/ | grep "virtualRouterIp" | grep -oP "\d+\.\d+\.\d+\.\d+" | head -n 1)
   								echo "Found Router IP $ROUTER_IP"
   
   							ip route add default via $ROUTER_IP

   Speichern Sie es unter: /usr/local/bin/configure_default_route.sh

2. Führen Sie den folgenden Befehl aus, um das Skript ausführbar zu machen:

   sudo chmod +x /usr/local/bin/configure_default_route.sh

3. Fügen Sie die folgende Zeichenfolge zu /etc/network/interfaces hinzu, damit das Skript bei jedem Systemstart gestartet wird:

   # OCI Emulated boot network interface
   								auto ens3
   								iface ens3 inet dhcp
   							post-up /usr/local/bin/configure_default_route.sh

Details

Wenn Sie eine sekundäre VNIC von Instanzen trennen, die aus importierten benutzerdefinierten Images gestartet wurden, kann der Vorgang wegen Timeout abgebrochen werden.

Workaround

Das Hotplug-Modul acpiphp muss geladen werden, damit sekundäre VNICs unter Linux ordnungsgemäß getrennt werden können. Wenn eine VNIC nicht getrennt werden kann, führen Sie den Befehl lsmod aus, um die Liste der geladenen Module anzuzeigen, und prüfen Sie die Liste auf acpiphp. Wenn das Modul nicht in der Liste angezeigt wird, laden Sie es, indem Sie den folgenden Befehl ausführen:

modprobe acpiphp

Wiederholen Sie den Vorgang zum Trennen der sekundären VNIC. Möglicherweise müssen Sie das System neu starten, damit der Vorgang erfolgreich abgeschlossen werden kann.

Details

Das Feature für sekundäre VNICs wird für die folgenden Betriebssysteme wegen eines Bugs im Kernel nicht unterstützt:

• CentOS 4, 5
• Oracle Linux 4, 5
• RHEL 4, 5

Sekundäre VNICs können nach einem Neustart nicht mehr ordnungsgemäß ausgeführt werden.

Workaround

Eine Lösung für dieses Problem ist in Arbeit.

Details

Wenn Sie versuchen, ein Image zu exportieren, tritt beim Export ein Fehler auf, der angibt, dass das Image ungültig ist. Dieser Fehler tritt nur in der Region "US West (Phoenix)" auf.

Workaround

So umgehen Sie dieses Problem:

1. Starten Sie eine neue Instanz basierend auf dem Image, das Sie exportieren möchten, und geben Sie eine der folgenden Ausprägungen für das Image an:

   • BM.Standard1.36

   • BM.DenseIO1.36

   • VM.DenseIO1.4

   • VM.DenseIO1.8

   • VM.DenseIO1.16

2. Erstellen Sie ein benutzerdefiniertes Image, indem Sie die unter So erstellen Sie ein benutzerdefiniertes Image beschriebenen Schritte ausführen.

Nachdem Sie das benutzerdefinierte Image erstellt haben, können Sie dieses neue Image exportieren.

Details

Wenn Sie eine SSH-Verbindung zu einer Bare-Metal-Instanz herstellen, muss der SSH-Client beim ersten Versuch den richtigen Schlüssel senden. Wenn Sie unter ~/.ssh oder in der Datei ~/.ssh/config mehrere SSH-Schlüssel konfiguriert haben, sendet der Client beim ersten Autorisierungsversuch möglicherweise nicht den korrekten Schlüssel, und folgende Fehlermeldung wird angezeigt:

Received disconnect from UNKNOWN port 65535:2: Too many authentication failures.

Workaround

Ändern Sie die Verbindungszeichenfolge im SSH-Befehl wie folgt: Verwenden Sie das configfile-Kennzeichen -F, um die Standardkonfigurationsdatei außer Kraft zu setzen, die Option -o IdentitiesOnly=yes, damit der SSH-Client den angegebenen Schlüssel verwendet, und das Kennzeichen der Identitätsdatei -i, um den zu verwendenden SSH-Schlüssel anzugeben, wie im folgenden Beispiel dargestellt:

ssh -F /dev/null -o IdentitiesOnly=yes -i /<path>/<ssh_key> -o ProxyCommand='ssh -i /<path>/<ssh_key> -W %h:%p -p 443...

Details

VM-Instanzen: Sie können serielle Konsolenverbindungen nur zu VM-Instanzen erstellen, die am 26. August 2017 oder danach gestartet wurden.

Bare-Metal-Instanzen: Sie können serielle Konsolenverbindungen nur zu Bare-Metal-Instanzen erstellen, die am 21. Oktober 2017 oder danach gestartet wurden.

Workaround

Wenn Sie seriellen Konsolenzugriff auf eine Instanz benötigen, die vor den für VM- und Bare-Metal-Instanzen angegebenen Tagen gestartet wurde, können Sie dieses Problem umgehen, indem Sie ein benutzerdefiniertes Image der Instanz erstellen. Wenn Sie eine neue Instanz basierend auf dem benutzerdefinierten Image starten, erhält die neue Instanz seriellen Konsolenzugriff. Informationen zum Erstellen eines benutzerdefinierten Images finden Sie unter Benutzerdefinierte Images verwalten.

Details

Der API-Vorgang ListImages umfasst Parameter für die serverseitige Filterung nach operatingSystem und operatingSystemVersion. Diese Parameter sind jedoch derzeit inaktiv. Außerdem enthält die Imageantwort-Objektdokumentation die Attribute operatingSystem und operatingSystemVersion, aber das Objekt gibt diese Felder derzeit nicht zurück.

Workaround

Informationen zu Plattformimages finden Sie im Anzeigenamen. Der Anzeigename für Plattformimages enthält das Betriebssystem und die Betriebssystemversion. Beispiel: Beim Plattformimage "Oracle-Linux-7.2-2016.09.18-0" ist "Oracle Linux" das Betriebssystem und die Version "7.2".

Dieser Fehler ist bekannt. Wir arbeiten an der Unterstützung dieser Parameter und Attribute.

Details

Wenn der Network Manager-Service installiert ist, kann eine Instanz möglicherweise nicht neu gestartet werden.

Workaround

Wenn der Network Manager-Service nicht erforderlich ist, können Sie ihn deinstallieren. Wenn der Network Manager-Service erforderlich ist, ändern Sie die Konfigurationsdatei der Netzwerkschnittstelle, bevor Sie die Instanz neu starten. Setzen Sie den NM_CONTROLLED-Konfigurationsschlüssel auf "no":

NM_CONTROLLED="no"

In der Regel befindet sich die Konfigurationsdatei der Netzwerkschnittstelle unter:

/etc/sysconfig/network-scripts/ifcfg-<interface_name>

Details

Einige FastConnect-Netzwerksetups verhindern automatische Patchupdates für Utilitys wie Oracle Ksplice.

Workaround

Ersetzen Sie in der Datei /etc/uptrack/uptrack.conf alle Instanzen von:

oraclecloud-updates-ksplice.oracle.com

durch:

updates.ksplice.<region>.oci.oraclecloud.com 

Beispiel: Wenn Ihre Hauptregion US West (Phoenix), ersetzen Sie:

oraclecloud-updates-ksplice.oracle.com

durch:

updates.ksplice.us-phoenix-1.oci.oracle.com

Dieser Workaround gilt für Servicegateways. Dies gilt nicht für private Endpunkte.

Details

Wenn Sie den OS Management-Service für Oracle Linux-Instanzen verwenden, die vor September 2019 erstellt wurden, wird auf der Seite "Instanzdetails" eventuell fälschlicherweise angegeben, dass der OS Management-Service aktiviert ist (Oracle Cloud Management Agent: Aktiviert), obwohl das nicht der Fall ist.

Dieses Problem wirkt sich auf Instanzen aus, die erstellt wurden, bevor das Kennzeichen isManagementDisabled in den Metadaten für Compute-Instanzen definiert wurde. Da dieses Kennzeichen nicht vorhanden ist, sind die Metadaten für diese Instanzen für den OS Management-Service nicht richtig festgelegt.

Workaround

Um dieses Problem zu beheben, setzen Sie das Kennzeichen isManagementDisabled auf "false":

1. Setzen Sie in der Agent-Konfiguration für die Instanz die Option isManagementDisabled auf "false":

   oci compute instance update --instance-id <instance_OCID> --agent-config '{"isManagementDisabled": false, "isMonitoringDisabled": false}'

2. Prüfen Sie mit der CLI, ob das Kennzeichen aktualisiert wurde:

   oci compute instance get --instance-id <instance_OCID>

   In der Ausgabe wird das aktualisierte Kennzeichen als "is-management-disabled": false angezeigt.

   {
     "data":
       "agent-config": {
         "is-management-disabled": false,
         "is-monitoring-disabled": false
       },
   ...
   }

3. Stellen Sie eine SSH-Verbindung zur Instanz her, und rufen Sie den Instance Metadata Service mit cURL auf. Prüfen Sie dann, ob das Kennzeichen innerhalb der Compute-Instanz aktualisiert wurde:

   curl http://169.254.169.254/opc/v1/instance/

   In der Ausgabe wird das aktualisierte Kennzeichen als "managementDisabled" : false angezeigt.

   {
     ...
     "agentConfig" : {
       "monitoringDisabled" : false,
       "managementDisabled" : false
     }
   }

Derzeit sind keine bekannten Probleme in Compute behoben.