Bekannte Probleme bei Compute
Diese bekannten Probleme wurden in Compute identifiziert.
Bekannte Probleme
ClamAV identifizierte Oracle Cloud Agent als Virus
- 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.
Hostnetzwerkbandbreite ist auf 60 Gbit/s begrenzt
- 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.
Confidential Computing für eine Instanz kann nicht bearbeitet werden
- 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.
Kernel Panic beim Booten, wenn SMEE aktiviert ist
- Details
- Confidential Computing wird auf Oracle Linux 9 nicht unterstützt.
- Workaround
- Eine Lösung für dieses Problem ist in Arbeit.
Soft Lockup beim Booten eines großen SEV-Gasts
- 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.
Mehrere Ausprägungsnamen werden für einige GPU-Ausprägungen verwendet
- 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.
SSH-Verbindungsprobleme bei macOS Ventura mit OpenSSH 9.0
- 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
Instanzen, die mit dem Plattformimage für CentOS 7 vom September 2022 ausgeführt werden, verlieren nach 24 Stunden die Verbindung zu Boot-Volumes
- 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.
Fehler beim Erstellen eines neuen externen vSwitch auf Bare-Metal-Ausprägungen der vorherigen Generation, die Windows Server 2016 ausführen
- 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.
Kernel Panic bei der Ausführung von Containern auf Ubuntu 20.04, Kernel 5.13.0-1033.39~20.04.1
- 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
Ältere VM-Instanzen mit E3/E4-Flex-Ausprägung können nicht gestartet werden, nachdem der Arbeitsspeicher auf mehr als 1.010 GB skaliert wurde
- 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.
In der Konsole wird Oracle Autonomous Linux als Image vom Typ Immer kostenlos angezeigt
- 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.
DNS funktioniert nicht wie erwartet auf Oracle Linux-Instanzen
- 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.
PCR-Werte ändern sich nach dem Neustart unter Linux 7.x
- 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.
Bei BM.Standard.A1.160-Instanzen ist die Netzwerkperformance für Anwendungen beeinträchtigt, die auf CPUs mit Socket 1 ausgeführt werden
- 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.
Oracle Cloud Agent veröffentlicht keine Metriken auf Windows-Instanzen in privaten Subnetzen, an die nur ein Servicegateway angehängt ist
- 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.
VM.Standard.A1.Flex-Instanzen unterstützen nur die Startoption für paravirtualisiertes Networking
- 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.
Begrenzen Sie die Größe von VM.Standard.A1. Flex-Ausprägung mit dem Netzwerktyp SR-IOV
- 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.
Fehlermeldung über ungültige Ausprägung/Image beim Erstellen von Intel- und AMD-Instanzen mit Terraform
- 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 wieShape <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]*$"]
Oracle Linux Cloud Developer-Images können nicht vom OS Management-Service verwaltet werden
- 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.
Fehlermeldung über ungültigen bucketName beim Importieren oder Exportieren eines benutzerdefinierten Images
- 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.
Instanz kann nicht aus Boot-Volume-Backup erstellt werden
- 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>
Instanz kann mit Terraform nicht aus Kapazitätsreservierung entfernt werden
- Details
- Eine Instanz kann nicht mit Terraform aus einer Kapazitätsreservierung entfernt werden.
- Lösungen
- Verwenden Sie eine der folgenden Lösungen:
Das Erstellen von mehr als 50 Kapazitätskonfigurationen führt zu einem internen Fehler
- 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.
Servicelimits für Kapazitätsreservierungen sind falsch
- 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.
Keine Servicekategorie für Kapazitätsreservierungen bei Beantragen einer Erhöhung des Servicelimits
- 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.
Instanzpool kann nicht erstellt werden, wenn Ressourcen Standardtags enthalten
- 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.
Fehlermeldung über fehlende Hostkapazität beim Erstellen von Compute-Instanzen
- Details
- Wenn Sie versuchen, eine Instanz zu erstellen, verläuft der Instanzstart nicht erfolgreich, und der Fehlercode
InternalError
und eine Meldung wieOut 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.
Die Verschlüsselung während der Übertragung kann für einen Boot-Volume-Anhang bearbeitet werden, wenn dies vom Image nicht unterstützt wird
- 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.
Oracle Cloud Agent-Plug-ins sind auf Domaincontrollern nicht verfügbar
- 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
-
-
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. -
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 -
Verwenden Sie
services.msc
, um den Ausführungsbenutzer des Service auf den Domainbenutzeraccount mit den entsprechenden Domaingruppen zu aktualisieren.
-
Boot-Volume-Backups größer als erwartet
- 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.
Vorübergehende Probleme bei SSH-Zugriff, DNS-Lookups und Zugriff auf den Metadatenservice
- 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
Über iSCSI angehängte Volumes werden beim Neustart nicht verbunden
- 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
Für iscsid-Service muss der automatische Neustart konfiguriert sein
- 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 deriscsid
-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.
VM-Instanzen werden mit einem über iSCSI angehängten Boot-Volume gestartet, wenn Sie einen Wert für das ipxeScript-Attribut angeben
- 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.
Bei den Instanzen hängt das System, nachdem "firewall-cmd --reload" ausgeführt wurde
- 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ürfirewall-cmd
. Führen Sie stattdessen den Befehlfirewall-cmd
zweimal aus. Verwenden Sie dabei den Parameterpermanent
, wenn Sie ihn zum ersten Mal aufrufen, um sicherzustellen, dass die iSCSI-Verbindung nicht verloren geht.Beispiel:
firewall-cmd --permanent firewall-cmd
Das Netzwerksymbol auf Windows 2016-Instanzen zeigt einen falschen Status an
- 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.
Bei Instanzen, auf denen das Oktober 2018-Release von Ubuntu 18.04 ausgeführt wird, hängt das System
- 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
kmsKeyId-Attribut ist Null
- 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.
Ubuntu-Instanz kann nach Aktivierung der Uncomplicated Firewall (UFW) nicht neu gestartet werden
- 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
Anmeldung bei Instanz nicht möglich, die vom neuen generalisierten benutzerdefinierten Windows-Image gestartet wurde
- 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.
Instanzen, die von benutzerdefinierten Ubuntu 16-Images gestartet werden, erfordern eine benutzerdefinierte Netzwerkkonfiguration
- 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:
-
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
-
Führen Sie den folgenden Befehl aus, um das Skript ausführbar zu machen:
sudo chmod +x /usr/local/bin/configure_default_route.sh
-
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
-
Timeout beim Trennen der sekundären VNIC für bestimmte Instanzen, die von importierten benutzerdefinierten Images gestartet wurden
- 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 Befehllsmod
aus, um die Liste der geladenen Module anzuzeigen, und prüfen Sie die Liste aufacpiphp
. 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.
Sekundäre VNIC funktioniert möglicherweise nicht bei älteren CentOS-, Oracle Linux- und RHEL-Images
- 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.
Fehler "Ungültiges Image" beim Exportieren eines Images
- 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:
-
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
-
-
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.
-
Authentifizierungsfehler beim Herstellen einer Verbindung zur seriellen Konsole für eine Bare-Metal-Instanz
- 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...
Serielle Konsolenverbindungen können für ältere Instanzen nicht verwendet werden
- 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.
Inaktive listImage-Parameter und fehlende Imageantwortfelder
- Details
- Der API-Vorgang ListImages umfasst Parameter für die serverseitige Filterung nach
operatingSystem
undoperatingSystemVersion
. Diese Parameter sind jedoch derzeit inaktiv. Außerdem enthält die Imageantwort-Objektdokumentation die AttributeoperatingSystem
undoperatingSystemVersion
, 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.
Instanz kann nicht neu gestartet werden, wenn der Network Manager-Service installiert ist
- 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>
Automatische Updates mit Oracle Ksplice sind bei einigen FastConnect-Netzwerksetups nicht erfolgreich
- 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:
durch:oraclecloud-updates-ksplice.oracle.com
updates.ksplice.<region>.oci.oraclecloud.com
Beispiel: Wenn Ihre Hauptregion US West (Phoenix), ersetzen Sie:
durch:oraclecloud-updates-ksplice.oracle.com
updates.ksplice.us-phoenix-1.oci.oracle.com
Dieser Workaround gilt für Servicegateways. Dies gilt nicht für private Endpunkte.
Fehlendes Kennzeichen ist für den OS Management-Service für Instanzen erforderlich, die vor September 2019 erstellt wurden
- 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":-
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}'
-
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 }, ... }
-
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 } }
-
Behobene Probleme
Derzeit sind keine bekannten Probleme in Compute behoben.