Beim Veröffentlichen Ihres Images des virtuellen Computers (VM) in Azure Marketplace wird es vom Azure-Team überprüft, um dafür die Startfähigkeit, Sicherheit und Kompatibilität mit Azure sicherzustellen. Falls Ihr VM-Image einen der Tests zur Überprüfung der hohen Qualitätsanforderungen nicht besteht, wird es nicht veröffentlicht. Sie erhalten eine Fehlermeldung, in der das Problem beschrieben ist.
In diesem Artikel werden Fehlermeldungen, die häufig bei der Veröffentlichung von VM-Images angezeigt werden, sowie die zugehörigen Lösungen erläutert.
Hinweis
Wenden Sie sich an den Partner Center-Support, falls Sie Fragen zu diesem Artikel oder Verbesserungsvorschläge haben.
Fehler bei der VM-Erweiterung
Überprüfen Sie, ob Ihr Image VM-Erweiterungen unterstützt.
Aktivieren Sie VM-Erweiterungen wie folgt:
Wählen Sie Ihren virtuellen Linux-Computer aus.
Navigieren Sie zu Diagnoseeinstellungen.
Aktivieren Sie Basismatrizen, indem Sie das Speicherkonto aktualisieren.
Wählen Sie Speichern.
Überprüfen Sie wie folgt, ob die VM-Erweiterungen richtig aktiviert wurden:
Wählen Sie auf dem virtuellen Computer die Registerkarte VM-Erweiterungen aus, und überprüfen Sie den Status der Linux-Diagnoseerweiterung.
Überprüfen Sie den Bereitstellungsstatus.
- Wenn der Status "Bereitstellung erfolgreich" ist, wurde der Testfall der Erweiterungen bestanden.
- Wenn der Status "Bereitstellung fehlgeschlagen" ist, ist der Testfall für Erweiterungen fehlgeschlagen, und Sie müssen das flag "Hartened" festlegen.
Liegt ein Fehler bei der VM-Erweiterung vor, lesen Sie die Informationen unter Verwenden der Linux-Diagnoseerweiterung zum Überwachen von Metriken und Protokollen, um sie zu aktivieren. Wenn die VM-Erweiterung nicht aktiviert sein soll, wenden Sie sich an das Supportteam, und lassen Sie die Erweiterung deaktivieren.
Problem bei der VM-Bereitstellung
Vergewissern Sie sich vor der Übermittlung Ihres Angebots, dass Sie den VM-Bereitstellungsprozess strikt befolgt haben. Unter dem Thema zum Testen von VM-Images finden Sie das JSON-Format zum Bereitstellen der VM.
Bereitstellungsprobleme können auf folgende Fehler zurückzuführen sein:
Szenario | Fehler | `Reason` | Lösung |
---|---|---|---|
1 | Ungültige virtuelle Festplatte (VHD) | Wenn der angegebene Cookiewert in der VHD-Fußzeile falsch ist, wird die VHD als ungültig angesehen. | Erstellen Sie das Image neu, und senden Sie die Anforderung. |
2 | Ungültiger Blobtyp | Fehler bei der VM-Bereitstellung, weil der verwendete Block ein Blocktyp und kein Seitentyp ist. | Erstellen Sie das Image als Seitentyp neu, und senden Sie die Anforderung. |
3 | Timeout bei der Bereitstellung oder nicht ordnungsgemäß generalisiert | Es liegt ein Problem mit der VM-Generalisierung vor. | Erstellen Sie das Image mit Generalisierung neu, und senden Sie die Anforderung. |
Hinweis
Weitere Informationen zur VM-Generalisierung finden Sie in den folgenden Ressourcen:
Hinweis
Wenn bei der Bereitstellung ein Fehler auftritt, da für das VM-Image eine benutzerdefinierte ARM-Vorlage bereitgestellt werden muss, aktivieren Sie in Partner Center auf der Seite „Technische Konfiguration“ das Kontrollkästchen „Erfordert eine benutzerdefinierte ARM-Vorlage für die Bereitstellung“. Dies hilft dem Zertifizierungsteam, die richtige Aktion für diese Anforderung zu ergreifen, ohne dass es für das Bereitstellungsproblem fehlschlägt.
VHD-Spezifikationen
Conectix-Cookie und andere VHD-Spezifikationen
Die Zeichenfolge „conectix“ ist Teil der VHD-Spezifikation. Sie wird als 8-Byte-Cookie in der VHD-Fußzeile für die Identifizierung des Dateierstellers definiert. Alle von Microsoft erstellten VHD-Dateien verfügen über dieses Cookie.
Ein Blob mit VHD-Formatierung sollte eine 512-Byte-Fußzeile mit dem folgenden Format aufweisen:
Felder in Festplatten-Fußzeilen | Größe (Byte) |
---|---|
Cookie | 8 |
Features | 4 |
Dateiformatversion | 4 |
Datenoffset | 8 |
Zeitstempel | 4 |
Anwendung des Erstellers | 4 |
Version des Erstellers | 4 |
Hostbetriebssystem des Erstellers | 4 |
Originalgröße | 8 |
Aktuelle Größe | 8 |
Datenträgergeometrie | 4 |
Datenträgertyp | 4 |
Checksum | 4 |
Eindeutige ID | 16 |
Gespeicherter Zustand | 1 |
Reserved | 427 |
VHD-Spezifikationen
Stellen Sie sicher, dass Ihre VHD die folgenden Kriterien erfüllt, um eine reibungslose Veröffentlichung zu ermöglichen:
- Das Cookie enthält die Zeichenfolge "conectix".
- Der Datenträgertyp lautet „Fixed“ (Feststehend).
- Die virtuelle Größe der VHD beträgt mindestens 20 MB.
- Die VHD wurde ausgerichtet. Die virtuelle Größe muss ein Vielfaches von 1 MB sein.
- Die Länge des VHD-Blobs entspricht der virtuellen Größe plus der Länge der VHD-Fußzeile (512).
Laden Sie die VHD-Spezifikation herunter.
Softwarecompliance für Windows
Wenn Ihre Windows-Imageanforderung aufgrund eines Softwarecomplianceproblems abgelehnt wird, besteht dies möglicherweise darin, dass Sie ein Windows-Image mit einer installierten SQL Server-Instanz erstellt haben. Stattdessen müssen Sie das entsprechende SQL Server-Versionsbasisimage aus Azure Marketplace verwenden.
Erstellen Sie kein eigenes Windows-Image, auf dem SQL Server installiert ist. Verwenden Sie die genehmigten SQL Server-Basisimages (Enterprise/Standard/Web) aus dem Azure Marketplace.
Wenn Sie Visual Studio oder ein lizenziertes Office-Produkt installieren möchten, holen Sie vorab die Genehmigung des Supportteams ein.
Weitere Informationen zum Auswählen einer genehmigten Basis finden Sie im Thema zum Erstellen eines virtuellen Computers aus einer genehmigten Basis.
Fehler bei der Testfallausführung des Toolkits.
Mit dem Microsoft Certification-Toolkit können Sie Testfälle ausführen und überprüfen, ob Ihre VHD oder Ihr Image mit der Azure-Umgebung kompatibel ist.
Laden Sie das Microsoft Certification-Toolkit herunter.
Linux-Testfälle
In der folgenden Tabelle sind die Linux-Testfälle aufgeführt, in denen das Toolkit ausgeführt wird. Die Testvalidierung wird in der Beschreibung angegeben.
Szenario | Testfall | Beschreibung |
---|---|---|
1 | Bashverlauf | Bashverlaufsdateien sollten vor dem Erstellen des VM-Images gelöscht werden. |
2 | Linux-Agent-Version | Die mindestens unterstützte Version des Azure Linux-Agents muss installiert sein. |
3 | Erforderliche Kernelparameter | Überprüft, ob die folgenden Kernelparameter festgelegt sind: console=ttyS0 earlyprintk=ttyS0 |
4 | Swap-Partition auf dem Betriebssystemdatenträger | Stellt sicher, dass Swap-Partitionen nicht auf dem Betriebssystemdatenträger erstellt werden. |
5 | Stammpartition auf dem Betriebssystemdatenträger | Erstellen Sie eine einzelne Stammpartition für den Betriebssystemdatenträger. |
6 | OpenSSL-Version | Sie müssen mindestens Version v0.9.8 von OpenSSL verwenden. |
7 | Python-Version | Dringend empfohlen wird Python-Version 2.6 oder höher. |
8 | Client-Alive-Intervall | Legen Sie das ClientAliveInterval auf 180 fest. Je nach Anforderung der Anwendung kann es auf einen Wert zwischen 30 und 235 festgelegt werden. Wenn Sie SSH für Ihre Endbenutzer aktivieren, muss dieser Wert gemäß der Beschreibung festgelegt werden. |
9 | Betriebssystemarchitektur | Es werden nur 64-Bit-Betriebssysteme unterstützt. |
10 | Automatische Aktualisierung | Gibt an, ob die automatische Aktualisierung des Linux-Agents aktiviert ist. |
Häufige Testfallfehler
In der folgenden Tabelle sind die häufigen Fehler angegeben, die beim Ausführen von Testfällen auftreten können:
Szenario | Testfall | Fehler | Lösung |
---|---|---|---|
1 | Testfall zur Überprüfung der Linux-Agent-Version | Die mindestens unterstützte Version des Azure Linux-Agents muss installiert sein.] (https://learn.microsoft.com/troubleshoot/azure/virtual-machines/support-extensions-agent-version) | Aktualisieren Sie die Version des Linux-Agents. Weitere Informationen finden Sie auf der Seite mit Updates für die Linux-Agent-Version. |
2 | Bashverlauf-Testfall | Es tritt ein Fehler auf, wenn die Größe des Bashverlaufs in Ihrem gesendeten Image 1 Kilobyte (KB) überschreitet. Die Größe ist auf 1 KB beschränkt, um sicherzustellen, dass in Ihrer Datei mit dem Bashverlauf keine potenziell vertraulichen Informationen erfasst werden. | Stellen Sie die VHD hierfür auf einer anderen funktionierenden VM bereit, und nehmen Sie Änderungen vor, um die Größe auf maximal 1 KB zu reduzieren. Löschen Sie beispielsweise die .bash_history -Dateien. |
3 | Testfall für erforderliche Kernelparameter | Dieser Fehler wird angezeigt, wenn der Wert für console diesen Wert nicht festgelegt ttyS0 ist. Überprüfen Sie, indem Sie den folgenden Befehl ausführen: cat /proc/cmdline |
Legen Sie den Wert für console die ttyS0 Anforderung fest, und übermitteln Sie die Anforderung erneut. |
4 | Testfall für das Client-Alive-Intervall | Falls im Toolkit-Ergebnis für diesen Testfall ein Fehler zurückgegeben wird, ist für ClientAliveInterval ein unzulässiger Wert vorhanden. |
Legen Sie den Wert auf ClientAliveInterval kleiner oder gleich 235 fest, und übermitteln Sie die Anforderung erneut. |
5 | smoke_test | Sie erhalten eine Fehlermeldung, wenn das Image aufgrund einer Kernel-Panik nicht gestartet oder neu gestartet werden kann. Sie können einige Informationen zur Anrufablaufverfolgung des Kernels aus der "Fehlerbeschreibung" abrufen. Wenn Sie die gesamte Anrufablaufverfolgung und das serielle Protokoll anzeigen möchten, können Sie einen virtuellen Computer in Azure mit Ihrem Image bereitstellen und die serielle Konsole in Ihrer VM-Ressource in der Azure-Portal überprüfen. | Wenn Sie einen virtuellen Computer in Azure erstellen, können Sie das serielle Konsolenprotokoll aus dem Azure-Portal herunterladen (Weitere Informationen zur seriellen Konsole finden Sie unter https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-linux |
6 | verify_dns_name_resolution | Dieser Testfall überprüft die DNS-Namensauflösung durch Ausführen von Befehl:Ping bing.com -c 5 -i 0.5 -O. Wenn eine öffentliche Webadresse "bing.com" nicht anpingt, tritt ein Fehler auf. | Informationen zum https://learn.microsoft.com/en-us/azure/virtual-machines/linux/azure-dns Hinzufügen der richtigen Einstellungen finden Sie unter |
7 | verify_no_pre_exist_users | Sie erhalten die Fehlermeldung "Kennwort des Benutzers XXXX wurde erkannt", wenn das Kennwort eines Benutzers erkannt wurde oder wenn der Schlüssel eines Benutzers erkannt wurde. | überprüfen Sie /etc/shadow-Datei, um festzustellen, ob sie über ein Kennwort eines Benutzers verfügt, falls ja, müssen Sie das Kennwort löschen und das Startverzeichnis des {Benutzers}/.ssh/authorized_keys datei nach der Fehlermeldung löschen. |
8 | validate_netvsc_reload | Sie erhalten den Fehler "failed". SSHException: SSH-Sitzung nicht aktiv.' wenn der virtuelle Computer nach ausführung unter dem Befehl nicht verbunden werden kann. Sie erhalten die Fehlermeldung "Kernel-Panik vom Knoten xx gefunden". wenn Kernel-Panik von der VM gefunden wird, nachdem der Befehl ausgeführt wurde: "modprobe -r hv_netvsc; modprobe hv_netvsc; ip link set eth0 down; ip link set eth0 up; dhclient -r eth0; dhclient eth0 ' | Überprüfen Sie die serielle Konsole, um festzustellen, ob während des Zeitraums der Ausführung über dem Befehl ein Fehler aufgetreten ist. Weitere Informationen zum Network Virtual Service Client (NetVSC) finden Sie unter.You can visit https://learn.microsoft.com/en-us/windows-hardware/drivers/network/sr-iov-synthetic-data-path for more details about Network Virtual Service Client (NetVSC). |
Windows-Testfälle
In der folgenden Tabelle sind die Windows-Testfälle aufgeführt, die vom Toolkit ausgeführt werden, sowie eine Beschreibung der Testüberprüfung:
Szenario | Testfälle | Beschreibung |
---|---|---|
1 | Betriebssystemarchitektur | Azure unterstützt nur 64-Bit-Betriebssysteme. |
2 | Abhängigkeit von Benutzerkonten | Die Ausführung der Anwendung sollte nicht vom Administratorkonto abhängen. |
3 | Failovercluster | Das Feature „Windows Server-Failoverclustering“ wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
4 | IPV6 | IPv6 wird in der Azure-Umgebung noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
5 | DHCP | Die Serverrolle „Dynamic Host Configuration-Protokoll“ wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
6 | Remotezugriff | Die Serverrolle „Remotezugriff (Direktzugriff)“ wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
7 | Rights Management Services | Rights Management Services. Die Serverrolle wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
8 | Windows-Bereitstellungsdienste | Windows-Bereitstellungsdienste. Die Serverrolle wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
9 | BitLocker-Laufwerkverschlüsselung | Die BitLocker-Laufwerkverschlüsselung wird auf der Betriebssystem-Festplatte nicht unterstützt, aber möglicherweise auf Datenträgern verwendet. |
10 | Internet Storage Name Server | Das Feature „Internet Storage Name Server“ wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
11 | Multipfad-E/A | Multipfad-E/A. Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
12 | Netzwerklastenausgleich | Netzwerklastenausgleich. Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
13 | Peer Name Resolution-Protokoll | Peer Name Resolution-Protokoll. Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
14 | SNMP-Dienste | Das Feature „SNMP-Dienste“ (Simple Network Management-Protokoll) wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
15 | WINS (Windows Internet Name Service) | WINS (Windows Internet Name Service). Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
16 | WLAN-Dienst | WLAN-Dienst. Diese Serverfunktion wird noch nicht unterstützt. Die Anwendung sollte nicht von diesem Feature abhängen. |
Wenn im Zusammenhang mit den obigen Testfällen Fehler auftreten, finden Sie in der Tabelle in der Spalte Beschreibung Hinweise zur Fehlerbehebung. Wenden Sie sich an das Supportteam, falls Sie weitere Informationen benötigen.
Überprüfung der Datenträgergröße
Datenträgeranforderungen mit einer Größe von mehr als 1.023 Gigabyte (GB) werden nicht genehmigt. Diese Regel gilt sowohl für Linux als auch für Windows.
Senden Sie die Anforderung mit einer Größe von maximal 1.023 GB noch einmal.
Überprüfung der Betriebssystemdatenträgergröße
In den folgenden Regeln finden Sie Einschränkungen hinsichtlich der Betriebssystem-Datenträgergröße. Überprüfen Sie beim Senden von Anforderungen, ob die Betriebssystem-Datenträgergröße innerhalb der Grenzen für Linux bzw. Windows liegt.
OS | Empfohlene VHD-Größe |
---|---|
Linux | 1 GB bis 1.023 GB |
Windows | 30 GB bis 250 GB |
Da VMs den Zugriff auf das zugrunde liegende Betriebssystem zulassen, sollten Sie sich vergewissern, dass die Größe der VHD ausreicht. Datenträger können erweitert werden, ohne dass es zu Ausfallzeiten kommt. Verwenden Sie eine Datenträgergröße zwischen 30 und 50 GB.
VHD-Größe | Tatsächlich belegte Größe | Lösung |
---|---|---|
>500 Tebibyte (TiB) | Nicht zutreffend | Wenden Sie sich wegen einer Ausnahmegenehmigung an das Supportteam. |
250-500 TiB | Differenz von >200 Gibibyte (GiB) zur Blobgröße | Wenden Sie sich wegen einer Ausnahmegenehmigung an das Supportteam. |
Hinweis
Größere Datenträgergrößen verursachen höhere Kosten und führen zu einer Verzögerung während des Setup- und Replikationsprozesses. Aufgrund dieser Verzögerung und Kosten kann das Supportteam eine begründete Ausnahmegenehmigung erteilen.
Überprüfungstest für WannaCry-Patches für Windows
Um einen potenziellen Angriff im Zusammenhang mit dem WannaCry-Virus zu verhindern, stellen Sie sicher, dass alle Windows-Image-Anforderungen mit dem neuesten Patch aktualisiert sind.
Sie können die Version der Imagedatei unter C:\windows\system32\drivers\srv.sys
oder srv2.sys
überprüfen.
In der folgenden Tabelle ist die gepatchte Mindestversion von Windows Server angegeben:
OS | Version |
---|---|
Windows Server 2008 R2 | 6.1.7601.23689 |
Windows Server 2012 | 6.2.9200.22099 |
Windows Server 2012 R2 | 6.3.9600.18604 |
Windows Server 2016 | 10.0.14393.953 |
Windows Server 2019 | NV |
Hinweis
Für WindowsServer2019 gelten keine obligatorischen Versionsanforderungen.
Überprüfung des SACK-Sicherheitsrisikopatches
Wenn Sie ein Linux-Image senden, wird Ihre Anforderung möglicherweise aufgrund von Problemen mit der Kernelversion abgelehnt.
Aktualisieren Sie den Kernel mit einer genehmigten Version, und senden Sie die Anforderung noch einmal. Die genehmigte Kernelversion finden Sie in der folgenden Tabelle. Die Versionsnummer muss mindestens der hier aufgeführten entsprechen.
Wenn das Image nicht mit einer der folgenden Kernelversionen installiert ist, aktualisieren Sie es mit den richtigen Patches. Fordern Sie die nötige Genehmigung vom Supportteam an, nachdem das Image mit diesen erforderlichen Patches aktualisiert wurde:
- CVE-2019-11477
- CVE-2019-11478
- CVE-2019-11479
Betriebssystemfamilie | Version | Kernel |
---|---|---|
Ubuntu | 14.04 LTS | 4.4.0-151 |
14.04 LTS | 4.15.0-1049-*-azure | |
16.04 LTS | 4.15.0-1049 | |
18.04 LTS | 4.18.0-1023 | |
18.04 LTS | 5.0.0-1025 | |
18.10 | 4.18.0-1023 | |
19.04 | 5.0.0-1010 | |
19.04 | 5.3.0-1004 | |
RHEL und CentOS | 6.10 | 2.6.32-754.15.3 |
7.2 | 3.10.0-327.79.2 | |
7.3 | 3.10.0-514.66.2 | |
7.4 | 3.10.0-693.50.3 | |
7,5 | 3.10.0-862.34.2 | |
7.6 | 3.10.0-957.21.3 | |
7.7 | 3.10.0-1062.1.1 | |
8.0 | 4.18.0-80.4.2 | |
8.1 | 4.18.0-147 | |
„7-RAW“ (7.6) | ||
„7-LVM“ (7.6) | 3.10.0-957.21.3 | |
RHEL-SAP 7.4 | TBD | |
RHEL-SAP 7.5 | TBD | |
SLES | SLES11SP4 (einschließlich SAP) | 3.0.101-108.95.2 |
SLES12SP1 für SAP | 3.12.74-60.64.115.1 | |
SLES12SP2 für SAP | 4.4.121-92.114.1 | |
SLES12SP3 | 4.4180-4.31.1 (Kernel-Azure) | |
SLES12SP3 für SAP | 4.4.180-94.97.1 | |
SLES12SP4 | 4.12.14-6.15.2 (Kernel-Azure) | |
SLES12SP4 für SAP | 4.12.14-95.19.1 | |
SLES15 | 4.12.14-5.30.1 (Kernel-Azure) | |
SLES15 für SAP | 4.12.14-5.30.1 (Kernel-Azure) | |
SLES15SP1 | 4.12.14-5.30.1 (Kernel-Azure) | |
Oracle | 6.10 | UEK2 2.6.39-400.312.2 UEK3 3.8.13-118.35.2 RHCK 2.6.32-754.15.3 |
7.0-7.5 | UEK3 3.8.13-118.35.2 UEK4 4.1.12-124.28.3 RHCK folgt auf obiges RHEL |
|
7.6 | RHCK 3.10.0-957.21.3 UEK5 4.14.35-1902.2.0 |
|
CoreOS Stable 2079.6.0 | 4.19.43* | |
Beta 2135.3.1 | 4.19.50* | |
Alpha 2163.2.1 | 4.19.50* | |
Debian | Jessie (Sicherheit) | 3.16.68-2 |
Jessie-Backports | 4.9.168-1+deb9u3 | |
Stretch (Sicherheit) | 4.9.168-1+deb9u3 | |
Debian GNU/Linux 10 (Buster) | Debian 6.3.0-18+deb9u1 | |
Buster, SID (Stretch-Backports) | 4.19.37-5 |
Bildgröße sollte sich in Vielfachen von Megabytes
Alle VHDs in Azure müssen eine virtuelle Größe aufweisen, die sich an einem Vielfachen von 1 Megabyte (MB) orientiert. Wenn Ihre VHD nicht empfohlene virtuelle Größe aufweist, wird Ihre Anforderung möglicherweise zurückgewiesen.
Halten Sie sich beim Konvertieren von einem Rohdatenträger in eine VHD an die Richtlinien. Stellen Sie sicher, dass die Größe des Rohdatenträgers ein Vielfaches von 1 MB ist. Weitere Informationen finden Sie unter Informationen zu nichtdornierten Verteilungen.
VM-Zugriff verweigert
Ein Problem vom Typ Zugriff verweigert beim Ausführen eines Testfalls auf der VM wird ggf. durch unzureichende Berechtigungen verursacht.
Überprüfen Sie, ob Sie für das Konto, unter dem die Testfälle ausgeführt werden, den richtigen Zugriff aktiviert haben. Aktivieren Sie den Zugriff zum Ausführen von Testfällen, falls dies noch nicht durchgeführt wurde. Wenn Sie den Zugriff nicht aktivieren möchten, können Sie die Ergebnisse des Selbsttestfalls mit dem Supportteam teilen.
Übermitteln Sie Ihre Anforderung mit einem Image mit deaktiviertem SSH für den Zertifizierungsprozess wie folgt:
Führen Sie das aktuelle Tool zum Testen der Zertifizierung für Azure-VMs für Ihr Image aus.
Erstellen Sie ein Supportticket. Achten Sie darauf, dass Sie den Toolkit-Bericht anfügen und die Angebotsdetails angeben:
- Angebotsname
- Herausgebername
- Plan-ID/SKU und Version
Übermitteln Sie Ihre Zertifizierungsanforderung erneut.
Hinweis
Wenn Sie ein gesperrtes VM-Image veröffentlichen, das ssh deaktiviert oder eingeschränkt hat, aktivieren Sie das Kontrollkästchen "Remotedesktop oder SSH deaktiviert" auf der Seite "Technische Konfiguration" des Partner Centers. Dadurch wird das Zertifizierungsteam darüber informiert, dass dies beabsichtigt ist, und die richtigen Überprüfungen für das Bild durchführen, ohne dass es für eingeschränkten Zugriff fehlschlägt.
Downloadfehler
In der Tabelle unten finden Sie alle Probleme, die auftreten können, wenn Sie das VM-Image mit einer SAS-URL (Shared Access Signature) herunterladen.
Fehler | `Reason` | Lösung |
---|---|---|
Nicht gefundenes Blob | Die VHD wurde entweder gelöscht oder vom angegebenen Speicherort verschoben. | |
Blob wird verwendet | Die VHD wird von einem anderen internen Prozess verwendet. Der Quellblobspeicher der VHD wird während der Veröffentlichung geändert. | Die VHD sollte sich nicht in einem verwendeten Zustand befinden, wenn Sie sie mit einer SAS-URL herunterladen. Verwenden/ändern Sie die VHD auch nicht, wenn die Veröffentlichung ausgeführt wird. |
Ungültige SAS-URL | Die zugehörige SAS-URL für die VHD ist falsch. | Rufen Sie die richtige SAS-URL ab. |
Ungültige Signatur | Die zugehörige SAS-URL für die VHD ist falsch. | Rufen Sie die richtige SAS-URL ab. |
Bedingter HTTP-Header | Die SAS-URL ist ungültig. | Rufen Sie die richtige SAS-URL ab. |
Ungültiger VHD-Name | Überprüfen Sie, ob Sonderzeichen wie das Prozentzeichen (% ) oder Anführungszeichen (" ) im VHD-Namen enthalten sind. |
Benennen Sie die VHD-Datei um, und entfernen Sie die Sonderzeichen. |
VM-Images müssen 1 MB freien Speicherplatz haben
Wenn Sie Ihr Image in Azure (mit GPT-Partition) veröffentlichen, wird dringend empfohlen , die ersten 2.048 Sektoren (1 MB) des Betriebssystemdatenträgers leer zu halten. Diese Anforderung dient dazu, Azure das Hinzufügen wichtiger Metadaten zum Image zu ermöglichen (z. B. Metadaten zur Verbesserung der Startzeit für Kunden, Abrechnung und andere Details). Dies ist eine Empfehlung für bewährte Methoden, wenn Sie bereits ein genehmigtes Basisimage verwenden und Ihr Bild über ein gültiges Abrechnungstag verfügt. Wenn Ihr Image jedoch nicht über ein gültiges Abrechnungstag verfügt, schlägt die Veröffentlichung möglicherweise fehl, wenn die ersten 1 MB des Betriebssystemdatenträgers nicht leer sind.
Wenn Sie ein eigenes Image erstellen, das über kein gültiges Abrechnungstag verfügt, stellen Sie sicher, dass die ersten 2.048 Sektoren (1 MB) des Betriebssystemdatenträgers leer sind. Andernfalls tritt bei der Veröffentlichung ein Fehler auf. Diese Anforderung gilt nur für den Betriebssystemdatenträger (nicht für andere Datenträger). Wenn Sie Ihr Image aus einer genehmigten Basis erstellen, ist es bereits über 1 MB leer. Sie müssen es also nicht separat bearbeiten.
Damit die ersten 1 MB auf Ihrem Betriebssystemdatenträger frei bleiben, führen Sie die Schritte im nächsten Abschnitt aus.
Beibehalten von 1 MB freien Speicherplatz am Anfang einer leeren VHD (2.048 Sektoren mit jeweils 512 Byte)
Diese Schritte gelten nur für Linux.
Erstellen Sie eine beliebige Art von Linux-VM, z. B. Ubuntu, CentOS usw. Füllen Sie die erforderlichen Felder aus, und wählen Sie dann Weiter: Datenträger aus.
Erstellen Sie einen nicht verwalteten Datenträger für Ihren virtuellen Computer. Verwenden Sie entweder die Standardwerte, oder geben Sie einen beliebigen Wert für Felder wie Größe des Betriebssystemdatenträgers, Typ des Betriebssystemdatenträgers und Verschlüsselungstyp an.
Wählen Sie nach dem Erstellen der VM im linken Bereich die Option Datenträger aus.
Fügen Sie Ihre VHD als Datenträger an Ihre VM an, um eine Partitionstabelle zu erstellen.
Wählen Sie Vorhandene Datenträger anfügen aus:
Suchen Sie nach Ihrem VHD-Speicherkonto.
Wählen Sie die Option Container und dann Ihre VHD aus.
Wählen Sie OK aus.
Ihre VHD wird als Datenträger „LUN 0“ hinzugefügt.
Starten Sie den virtuellen Computer neu.
Melden Sie sich nach dem Neustart der VM bei der VM an, indem Sie PuTTY oder einen anderen Client verwenden, und führen Sie den Befehl
sudo -i
aus, um root-Zugriff zu erhalten.Erstellen Sie auf Ihrer VHD eine Partition.
Geben Sie den Befehl
fdisk /dev/sdb
ein.Geben Sie
p
ein, um die vorhandene Partitionsliste Ihrer VHD anzuzeigen.Geben Sie
d
ein, um alle vorhandenen Partitionen zu löschen, die auf Ihrer VHD verfügbar sind. Sie können diesen Schritt überspringen, falls er für Sie nicht erforderlich ist.Geben Sie
n
ein, um eine neue Partition zu erstellen, und wählen Sie als Typp
(primäre Partition) aus.Geben Sie „2048“ als Wert für den ersten Sektor (First sector) ein. Sie können Last sector (Letzter Sektor) als Standardwert beibehalten.
Wichtig
Alle vorhandenen Daten werden gelöscht, bis 2048 Sektoren (mit jeweils 512 Bytes) frei sind. Erstellen Sie eine Sicherung der VHD, bevor Sie eine neue Partition erstellen.
Geben Sie
w
ein, um die Erstellung der Partition zu bestätigen.Sie können die Partitionstabelle überprüfen, indem Sie den Befehl
n fdisk /dev/sdb
ausführen undp
eingeben. Sie sehen, dass die Partition mit dem Offsetwert „2048“ erstellt wurde.
Trennen Sie die VHD vom virtuellen Computer, und löschen Sie den virtuellen Computer.
Standardanmeldeinformationen
Senden Sie zusammen mit der übermittelten VHD niemals Standardanmeldeinformationen. Das Hinzufügen von Standardanmeldeinformationen macht die VHD anfälliger gegenüber Sicherheitsbedrohungen. Erstellen Sie stattdessen beim Senden der VHD eigene Anmeldeinformationen.
DataDisk wurde falsch zugeordnet
Ein Zuordnungsproblem kann auftreten, wenn eine Anforderung mit mehreren Datenträgern übermittelt wird, die nicht als entsprechende Sequenz vorliegen. Die Nummerierungsreihenfolge für die drei Datenträger muss beispielsweise 0, 1, 2 lauten. Alle anderen Reihenfolgen werden als Zuordnungsproblem behandelt.
Senden Sie die Anforderung mit ordnungsgemäßer Sequenzierung der Datenträger noch einmal.
Falsche Betriebssystemzuordnung
Beim Erstellen eines Images kann dieses der falschen Betriebssystembezeichnung zugeordnet oder zugewiesen werden. Wenn Sie beim Erstellen des Images beispielsweise Windows als Teil des Betriebssystemnamens auswählen, darf der Betriebssystem-Datenträger nur mit Windows installiert werden. Die gleiche Anforderung gilt für Linux.
VM nicht generalisiert
Wenn alle Images aus Azure Marketplace wiederverwendet werden sollen, muss die Betriebssystem-VHD generalisiert werden.
Unter Linux wird mit dem folgenden Prozess eine Linux-VM generalisiert und als separate VM erneut bereitgestellt.
Geben Sie im SSH-Fenster den folgenden Befehl ein:
sudo waagent -deprovision+user
Unter Windows generalisieren Sie Windows-Images mithilfe von
sysreptool
.Weitere Informationen zum Tool
sysreptool
finden Sie unter Übersicht über Sysprep (Systemvorbereitung).
DataDisk-Fehler
In der folgenden Tabelle sind Fehlerbehebungsoptionen für Fehler in Verbindung mit dem Datenträger aufgeführt:
Fehler | `Reason` | Lösung |
---|---|---|
DataDisk- InvalidUrl: |
Dieser Fehler kann darauf zurückzuführen sein, dass beim Übermitteln des Angebots eine ungültige logische Gerätenummer (Logical Unit Number, LUN) angegeben wurde. | Vergewissern Sie sich, dass sich die Sequenz der LUN-Nummern für den Datenträger in Partner Center befindet. |
DataDisk- NotFound: |
Dieser Fehler kann darauf zurückzuführen sein, dass sich ein Datenträger nicht unter einer angegebenen SAS-URL befindet. | Vergewissern Sie sich, dass der Datenträger unter der angegebenen SAS-URL vorhanden ist. |
Problem beim Remotezugriff
Sie erhalten diesen Fehler, wenn für das Windows-Image nicht die Remotedesktopprotokoll-Option (RDP) aktiviert ist.
Aktivieren Sie vor dem Senden den RDP-Zugriff für Windows-Images.
Bash-Verlauf fehlgeschlagen
Dieser Fehler tritt auf, wenn die Größe des Bashverlaufs in Ihrem gesendeten Image 1 Kilobyte (KB) überschreitet. Die Größe ist auf 1 KB beschränkt, um zu verhindern, dass die Datei potenziell vertrauliche Informationen enthält.
Löschen Sie den Bashverlauf wie folgt:
Stellen Sie den virtuellen Computer bereit, und wählen Sie im Azure-Portal die Option Befehl ausführen aus.
Wählen Sie die erste Option RunShellScript aus, und führen Sie dann den folgenden Befehl aus:
cat /dev/null > ~/.bash_history && history -c
.Starten Sie den virtuellen Computer neu, nachdem der Befehl erfolgreich ausgeführt wurde.
Generalisieren Sie den virtuellen Computer, erstellen Sie die Image-VHD, und beenden Sie den virtuellen Computer.
Übermitteln Sie das generalisierte Image erneut.
Überprüfungen der virtuellen Netzwerkanwendung
Während der Marketplace-Imagezertifizierung wird ein VM-Angebot, das eine Network Virtual Appliance (NVA) ist, mithilfe von Tests überprüft, die generisch für jedes VM-Angebot sind, und NVA-Testfälle, die in der folgenden Tabelle aufgeführt sind. Als Ziel dieser NVA-spezifischen Überprüfungen soll ermittelt werden, wie gut das NVA-Image mit dem SDN-Stapel orchestriert wird.
Testfall | Schritte zum Ausführen des Testfalls | Lösung |
---|---|---|
VHD-Zugriff | Vergewissern Sie sich, dass die richtige SAS-URL für die VHD angegeben ist, die Berechtigungen so festgelegt sind, dass der Zugriff gestattet wird, und das NVA-Image generalisiert ist. | Überprüfen Sie das NVA-Image und die angegebene URL. |
NVA-Bereitstellung | Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Vergewissern Sie sich, dass die Bereitstellung in 20 Minuten abgeschlossen ist. | Wenn die Bereitstellung nicht innerhalb von 20 Minuten abgeschlossen ist, überprüfen Sie das NVA-Image. |
NVA-Neustart | Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Wechseln Sie dann in Azure-Portal zum virtuellen Computer, und wählen Sie im linken Bereich "Support + Problembehandlung" die Option "Erneut bereitstellen+ Erneut anwenden" aus, und stellen Sie den virtuellen Computer erneut bereit. Überprüfen Sie nach Abschluss der erneuten Bereitstellung, ob der Status der VM Wird ausgeführt lautet und der NIC-Port 22 mit dem Netcat-Befehl erreichbar ist. | Wenn der virtuelle Computer nach dem Neustart nicht angezeigt wird, liegt möglicherweise ein Problem mit dem NVA-Image vor. Ein Fehler beim Netcat-Test kann auftreten, wenn die NIC nach dem Neustart nicht gestartet werden konnte, obwohl die VM ausgeführt wurde. Warten Sie einige Minuten, und versuchen Sie es erneut. Wenn es nach 20 Minuten immer noch fehlschlägt, liegt möglicherweise ein Problem mit dem NVA-Bild vor. |
Erneute NVA-Bereitstellung | Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Stellen Sie dann die VM erneut bereit. Überprüfen Sie, ob der Status der VM Wird ausgeführt lautet und der NIC-Port 22 mit dem Netcat-Befehl erreichbar ist. | Wenn die erneute Bereitstellung nicht innerhalb von 15 Minuten abgeschlossen ist, liegt möglicherweise ein Problem mit dem NVA-Image vor. Ein Fehler beim Netcat-Test kann auftreten, wenn die NIC nach dem Neustart nicht gestartet werden konnte, obwohl die VM ausgeführt wurde. Warten Sie einige Minuten, und versuchen Sie es erneut. Wenn es nach 20 Minuten immer noch fehlschlägt, liegt möglicherweise ein Problem mit dem NVA-Bild vor. |
Hochverfügbarkeit | Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Es sollte entweder keine öffentliche IP-Adresse an die NIC angefügt sein, oder wenn eine öffentliche IP-Adresse angefügt ist, sollte die SKU eine Standard-SKU und die IP-Zuordnungsmethode statisch sein. Richten Sie im selben virtuellen Netzwerk einen Azure Internal Load Balancer mit der nachstehenden Konfiguration ein. – Lastenausgleich mit Standard-SKU – Front-End-IP-Adresse mit dynamischer Zuordnungsmethode für private IP-Adressen – Integritätstests mit TCP, Port 22 mit einem Wiederholungsintervall von 15 Sekunden – Eine Lastenausgleichsregel, bei der das Protokoll auf alle und „Floating IP-Adresse aktivieren“ auf FALSE festgelegt ist – Back-End-Pool, der auf NVA-VM verweist Sobald die Einrichtung abgeschlossen ist, überprüfen Sie mithilfe des Netcat-Befehls, ob die NVA-VM über den Lastenausgleich erreichbar ist. |
Ist das NVA nicht über den Lastenausgleich erreichbar, überprüfen Sie die Einrichtung der VM, des Lastenausgleichs und des Features für Hochverfügbarkeitsports. Wenn alles korrekt ist, liegt möglicherweise ein Problem mit dem NVA-Bild vor. |
VNET-Peering | Stellen Sie einen virtuellen Computer VM1 mithilfe des NVA-Images mit einer NIC in einem virtuellen Netzwerk-VNET1 bereit. Stellen Sie in einem anderen virtuellen Netzwerk VNET2 einen virtuellen Computer VM2 mit jedem Linux-Image bereit, z. B. Ubuntu, mit einer NIC und VM-Einstellungen als Dynamische IP-Zuordnungsmethode und einfache SKU. Erstellen Sie ein VNET-Peering zwischen VNET1 und VNET2, und konfigurieren Sie Datenverkehr zum virtuellen Remotenetzwerk als Zulassen (Standard). Sobald die Einrichtung abgeschlossen ist, überprüfen Sie mithilfe des Netcat-Befehls, ob von VM2 aus die private IP-Adresse der NIC auf der NVA-VM1 erreicht werden kann. |
Wenn die NVA-VM1 von VM2 aus nicht erreichbar ist, überprüfen Sie, ob das VNET-Peering ordnungsgemäß konfiguriert ist, und versuchen Sie es erneut. Wenn es immer noch nicht funktioniert, liegt möglicherweise ein Problem mit dem NVA-Bild vor. |
Beschleunigter Netzwerkbetrieb (Accelerated Networking, AN) | Stellen Sie eine VM mit dem NVA und einer NIC mit aktiviertem beschleunigtem Netzwerkbetrieb bereit. Sie können den beschleunigten Netzwerkbetrieb für eine NIC beim Erstellen der VM oder nach dem Erstellen der VM in den NIC-Eigenschaften aktivieren. Vergewissern Sie sich, dass die VM aktiv ist und ausgeführt wird. | Wenn die Bereitstellung fehlschlägt, überprüfen Sie, ob das NVA-Image beschleunigte Netzwerke unterstützt. |
Multi-NIC – Basic | Stellen Sie eine VM mithilfe des NVA mit drei NICs mit dynamischer IP-Zuordnungsmethode und Basic-SKU bereit. Rufen Sie die privaten IP- und MAC-Adressen für alle NICs ab (Anweisungen dazu finden Sie unter Anzeigen der Einstellungen von Netzwerkschnittstellen). Stellen Sie dann die VM erneut bereit, und vergewissern Sie sich, dass die privaten IP- und MAC-Adressen für alle NICs die gleichen sind wie vor der erneuten Bereitstellung. | Wenn sich die private IP- und MAC-Adresse für alle NICs nach der erneuten Bereitstellung ändern, liegt möglicherweise ein Problem mit dem NVA-Image vor. |
Netzwerkunterbrechung | Stellen Sie einen virtuellen Computer mithilfe der NVA mit einer NIC bereit. Erstellen Sie anschließend eine Netzwerksicherheitsgruppe (NSG), und wenden Sie diese an, um den gesamten Datenverkehr an die NVA-VM zu blockieren. Vergewissern Sie sich dann, dass der Status der VM Wird ausgeführt lautet. | Wenn nach dem Anwenden von NSG der virtuelle Computer heruntergeht, liegt möglicherweise ein Problem mit dem NVA-Image vor. |
Für weitere Informationen oder Fragen öffnen Sie einen Azure-Supportfall.
Netcat-Übersicht:
Netcat ist ein Befehl, der eine TCP- oder UDP-Verbindung zwischen zwei Computern herstellen kann. Das bedeutet, dass er über einen offenen Port schreiben und lesen kann. Während der NVA-Überprüfungen führen wir den Netcat-Befehl von einer VM aus, die sich im gleichen virtuellen Netzwerk wie der NVA-VM befindet, um zu testen, ob TCP-Port 22 erreichbar ist. Die Befehlssyntax lautet nc <destination_ip_address> <destination_port>
. Dabei gilt Folgendes:
- destination_ip_address ist die private IP-Adresse, die der VM-NIC zugewiesen ist.
- destination_port ist die Portnummer des NVA. In NVA-Testfällen wird 22 verwendet.
Beispiel: nc 192.168.1.1 22
Anfordern einer Ausnahme für VM-Images für ausgewählte Tests
Herausgeber können für einige Tests, die während der VM-Zertifizierung durchgeführt werden, Ausnahmen anfordern. Ausnahmen werden in seltenen Fällen gewährt, wenn der Herausgeber die Anforderung fundiert begründet. Das Zertifizierungsteam behält sich das Recht vor, Ausnahmen jederzeit abzulehnen oder zu genehmigen.
In diesem Abschnitt werden allgemeine Szenarien, in denen Herausgeber eine Ausnahme anfordern, und die entsprechenden Vorgehensweisen beschrieben.
Szenarien für eine Ausnahme
Herausgeber fordern Ausnahmen normalerweise in den folgenden Fällen an:
Ausnahme für einen oder mehrere Testfälle: Wenden Sie sich an den Partner Center-Support, um Ausnahmen für Testfälle anzufordern.
Gesperrte VMs/kein Root-Zugriff: Bei einigen Herausgebern müssen VMs gesperrt werden, weil Software (z. B. Firewalls) auf der VM installiert ist. Laden Sie in diesem Fall das Certified-Testtool herunter, und übermitteln Sie den Bericht an den Partner Center-Support.
Benutzerdefinierte Vorlagen: Einige Herausgeber veröffentlichen VM-Images, für die eine benutzerdefinierte ARM-Vorlage (Azure Resource Manager) zum Bereitstellen der VMs erforderlich ist. Übermitteln Sie in diesem Fall die benutzerdefinierten Vorlagen im Partner Center-Support , die vom Zertifizierungsteam zur Überprüfung verwendet werden sollen.
Zu übermittelnde Informationen für Ausnahmeszenarien
Wenden Sie sich an den Partner Center-Support, um eine Ausnahme für eines der Szenarien anzufordern, und geben Sie die folgenden Informationen an:
Herausgeber-ID: Geben Sie die Herausgeber-ID aus Ihrem Partner Center-Portal ein.
Angebots-ID/Name: Geben Sie die Angebots-ID oder den Namen ein.
SKU/Plan-ID: Geben Sie die Plan-ID oder SKU des VM-Angebots ein.
Version: Geben Sie die Version des VM-Angebots ein, für das eine Ausnahme erforderlich ist.
Ausnahmetyp: Wählen Sie zwischen Tests, gesperrten virtuellen Computern und benutzerdefinierten Vorlagen.
Grund für die Anforderung: Geben Sie den Grund für die Ausnahmeanforderung sowie Informationen zu den auszuschließenden Tests an.
Zeitachse: Geben Sie das Enddatum für Ihre Ausnahme ein.
Anhang. Angefügte Dokumente mit wichtigen Nachweisinformationen:
- Fügen Sie für gesperrte virtuelle Computer den Testbericht an.
- Fügen Sie für benutzerdefinierte Vorlagen die benutzerdefinierte ARM-Vorlage als Anlage an.
Wenn Sie diese Anlagen nicht anfügen, wird die Anforderung abgelehnt.
Beheben einer Sicherheitsanfälligkeit oder eines Exploits in einem VM-Angebot
In diesem Abschnitt wird beschrieben, wie Sie ein neues VM-Image bereitstellen, wenn ein Sicherheitsrisiko oder Exploit bei einem Ihrer VM-Images erkannt wird. Dies gilt nur für Azure-VM-Angebote, die auf Azure Marketplace veröffentlicht werden.
Hinweis
Sie können weder das letzte VM-Image aus einem Plan entfernen noch den Verkauf des letzten Plans für ein Angebot einstellen.
Führen Sie eine der folgenden Aktionen aus:
- Falls Sie über ein neues VM-Image als Ersatz für das gefährdete VM-Image verfügen, helfen Ihnen die Informationen unter Bereitstellen eines korrigierten VM-Images weiter.
- Wenn Sie kein neues VM-Image als Ersatz für das einzige VM-Image in einem Plan besitzen und den Plan beenden möchten, können Sie den Vertrieb des Plans einstellen.
- Wenn das einzige VM-Image im Angebot nicht ersetzt werden soll, empfiehlt es sich, den Vertrieb des Angebots einzustellen.
Bereitstellen eines korrigierten VM-Images
Gehen Sie wie folgt vor, um ein korrigiertes VM-Image als Ersatz für ein VM-Image mit Sicherheitsrisiko oder Exploit bereitzustellen:
- Stellen Sie ein neues VM-Image bereit, um das Sicherheitsrisiko oder Exploit zu beheben.
- Entfernen Sie das VM-Image mit dem Sicherheitsrisiko oder Exploit.
- Veröffentlichen Sie das Angebot erneut.
Bereitstellen eines neuen VM-Images zur Behebung des Sicherheitsrisikos oder Exploits
Bereiten Sie die technischen Ressourcen für das hinzuzufügende VM-Image vor, um diese Schritte ausführen zu können. Weitere Informationen finden Sie unter Erstellen eines virtuellen Computers mit einer genehmigten Basis oder Erstellen eines virtuellen Computers mit einem eigenen Image und Generieren eines SAS-URIs für Ihr VM-Image.
Melden Sie sich bei Partner Center an.
Wählen Sie auf der Startseite die Kachel Marketplace-Angebote aus.
Wählen Sie in der Spalte Angebotsalias das Angebot aus.
Wählen Sie die Registerkarte Planübersicht und dann den entsprechenden Plan aus.
Wählen Sie auf der Registerkarte Technische Konfiguration unter VM-Images die Option + VM-Image hinzufügen aus.
Hinweis
Sie können einem Plan jeweils nur ein VM-Image hinzufügen. Wenn Sie mehrere VM-Images hinzufügen möchten, sollten Sie das erste VM-Image veröffentlichen, bevor Sie das nächste hinzufügen.
Geben Sie in den angezeigten Feldern eine neue Datenträgerversion und das VM-Image an.
Wähen Sie Entwurf speichern aus.
Entfernen Sie als Nächstes das VM-Image mit dem Sicherheitsrisiko.
Entfernen des VM-Images mit dem Sicherheitsrisiko oder Exploit
- Melden Sie sich bei Partner Center an.
- Wählen Sie auf der Startseite die Kachel Marketplace-Angebote aus.
- Wählen Sie in der Spalte Angebotsalias das Angebot aus.
- Wählen Sie die Registerkarte Planübersicht und dann den entsprechenden Plan aus.
- Wählen Sie auf der Registerkarte Technische Konfiguration unter VM-Images die Option VM-Image entfernen neben dem zu entfernenden VM-Image aus.
- Wählen Sie im Dialogfeld die Option Weiter aus.
- Wähen Sie Entwurf speichern aus.
Veröffentlichen Sie das Angebot anschließend erneut.
Erneutes Veröffentlichen des Angebots
- Wählen Sie Überprüfen und veröffentlichen aus.
- Wenn Sie Informationen für das Zertifizierungsteam bereitstellen müssen, fügen Sie diese dem Feld Hinweise zur Zertifizierung hinzu.
- Wählen Sie Veröffentlichen aus.
Unter Überprüfen und Veröffentlichen von Angeboten erfahren Sie, wie Sie die Veröffentlichung abschließen.
VM-Images mit beschränktem Zugriff oder erforderlichen benutzerdefinierten Vorlagen
Gesperrtes (oder) deaktiviertes SSH-Angebot
Images, die entweder mit deaktiviertem SSH (für Linux) oder deaktiviertem RDP (für Windows) veröffentlicht werden, werden als gesperrte VMs behandelt. Es gibt spezielle Geschäftsszenarios, in denen Herausgeber nur wenigen oder keinen Benutzern den beschränkten Zugriff gewähren.
Gesperrte VMs lassen die Ausführung bestimmter Zertifizierungsbefehle möglicherweise während Validierungsüberprüfungen nicht zu.
Benutzerdefinierte Vorlagen
Im Allgemeinen folgen alle unter einem virtuellen Computer veröffentlichten Images der Standard-ARM-Vorlage für die Bereitstellung. Es gibt jedoch Szenarien, in denen der Herausgeber erfordert, dass während der Bereitstellung von VMs Anpassungen vorgenommen werden (z. B. die Konfiguration mehrerer Netzwerkschnittstellen).
Je nach den folgenden Szenarien (nichtexextive) verwenden Herausgeber benutzerdefinierte Vorlagen für die Bereitstellung der VM:
- VM erfordert zusätzliche Netzwerksubnetze.
- Weitere Metadaten, die in arm-Vorlage eingefügt werden sollen.
- Es sind Befehle für die Ausführung der ARM-Vorlage erforderlich.
VM-Erweiterungen
Erweiterungen für virtuelle Azure-Computer sind kleine Anwendungen, die Konfigurations- und Automatisierungsaufgaben auf Azure-VMs nach der Bereitstellung ermöglichen. Wenn z.B. Software auf einem virtuellen Computer (virtual machine, VM) installiert werden muss, Virenschutz oder die Ausführung eines Skripts erforderlich ist, kann eine VM-Erweiterung verwendet werden.
Folgendes muss für Überprüfungen der Linux-VM-Erweiterung im Image enthalten sein:
- Die mindestens unterstützte Version des Azure Linux-Agents muss installiert sein.] (https://learn.microsoft.com/troubleshoot/azure/virtual-machines/support-extensions-agent-version)
- Python über Version 2.6
Weitere Informationen finden Sie unter VM-Erweiterung.
Überprüfung der Integrität des Bilds
Wenn Sie ein Image erstellen und Datenträger aus dem Image erstellen, um die Integrität des Bilds zu überprüfen, beachten Sie, dass die ersten 1 MB für eine optimierte Leistung reserviert sind und die letzten 512 Bytes für die VHD-Fußzeile reserviert sind. Ignorieren Sie sie also, während Sie die Integrität des Bilds überprüfen.
Zugehöriger Inhalt
- Konfigurieren von Vm-Angebotseigenschaften
- Aktive Marketplace-Prämien
- Wenden Sie sich an den Partner Center-Support, wenn Sie Fragen oder Verbesserungsvorschläge haben.