Résoudre les problèmes de certification des machines virtuelles

Lorsque vous publiez l’image d’une machine virtuelle sur Place de marché Azure, l’équipe Azure la valide pour s’assurer qu’elle est démarrable, sécurisée et compatible avec Azure. Si votre image de machine virtuelle échoue à l’un des tests de haute qualité, elle ne sera pas publiée. Vous recevrez un message d’erreur qui décrit le problème.

Cet article présente les messages d'erreur les plus couramment rencontrés lors de la publication d'images de machine virtuelle, ainsi que les solutions associées.

Remarque

Si vous avez des questions sur cet article ou des suggestions d’amélioration, contactez le support d’Espace partenaires.

Échec de l’extension de machine virtuelle

Déterminez si votre image prend en charge les extensions de machine virtuelle.

Pour activer les extensions de machine virtuelle :

  1. Sélectionnez votre machine virtuelle Linux.

  2. Accédez à Paramètres de diagnostic.

  3. Activez les matrices de base en mettant à jour le compte de stockage.

  4. Sélectionnez Enregistrer.

    Screenshot that displays how to enable guest-level monitoring.

Pour vérifier que les extensions de machine virtuelle sont correctement activées :

  1. Dans la machine virtuelle, sélectionnez l'onglet Extensions de machine virtuelle, puis vérifiez l'état de l'Extension de diagnostic Linux.

  2. Vérifiez l’état de l’approvisionnement.

    • Si l’état est approvisionnement réussi, le cas de test des extensions a réussi.
    • Si l’état a échoué, le cas de test des extensions a échoué et vous devez définir l’indicateur renforcé.

    Screenshot showing that provisioning succeeded.

    Si l'extension de machine virtuelle échoue, accédez à Utiliser l'Extension de diagnostic Linux pour superviser les métriques et les journaux afin de l'activer. Si vous ne souhaitez pas que l'extension de machine virtuelle soit activée, contactez l'équipe du support technique et demandez-lui de la désactiver.

Problème d’approvisionnement de machines virtuelles

Assurez-vous d'avoir rigoureusement suivi le processus d'approvisionnement de la machine virtuelle avant de soumettre votre offre. Pour afficher le format JSON à des fins d’approvisionnement de la machine virtuelle, consultez Tester une image de machine virtuelle.

Les problèmes de provisionnement peuvent inclure les scénarios d’échec suivants :

Scénario Erreur Motif Solution
1 Disque dur virtuel (VHD) non valide Si la valeur de cookie spécifiée dans le pied de page du disque dur virtuel est incorrecte, le disque dur virtuel est considéré comme non valide. Recréez l'image et envoyez la demande.
2 Type d'objet blob non valide Le provisionnement de la machine virtuelle a échoué car le blob utilisé est de type bloc et non de type page. Recréez l’image en tant que type de page et envoyez la demande.
3 Expiration du délai de provisionnement ou généralisation incorrecte Il y a un problème avec la généralisation de la machine virtuelle. Recréez l'image avec la généralisation et envoyez la demande.

Remarque

Pour plus d'informations sur la généralisation d'une machine virtuelle, consultez :

Remarque

Si l’approvisionnement échoue car l’image de la machine virtuelle nécessite un modèle ARM personnalisé pour être déployée, cochez la case « Nécessite un modèle ARM personnalisé pour le déploiement » dans la page « Configuration technique » d’Espace partenaires. Cela permet à l’équipe de certification de prendre les mesures appropriées pour cette demande sans l’avoir échoué pour le problème d’approvisionnement.

Custom ARM template checkbox

Spécifications du disque dur virtuel (VHD)

La chaîne « conectix » fait partie de la spécification du disque dur virtuel. Elle est définie en tant que cookie de 8 octets dans le pied de page du disque dur virtuel qui identifie le créateur du fichier. Tous les fichiers VHD créés par Microsoft possèdent ce cookie.

Un blob au format VHD doit avoir un pied de page de 512 octets au format suivant :

Champs du pied de page du disque dur Taille (en octets)
Cookie 8
Fonctionnalités 4
Version de format du fichier 4
Décalage des données 8
Horodatage 4
Application de création 4
Version de création 4
Système d’exploitation hôte de création 4
Taille d'origine 8
Taille actuelle 8
Géométrie du disque 4
Type du disque 4
Checksum 4
ID unique 16
État enregistré 1
Reserved 427

Spécifications de disque dur virtuel

Pour garantir une expérience de publication fluide, assurez-vous que le disque dur virtuel répond aux critères suivants :

  • Le cookie contient la chaîne 'conectix'.
  • Le type de disque est fixe.
  • La taille virtuelle du disque dur virtuel est d’au moins 20 Mo.
  • Le disque dur virtuel est aligné. La taille virtuelle doit être un multiple de 1 Mo.
  • La longueur du blob VHD est égale à la taille virtuelle plus la longueur du pied de page VHD (512).

Téléchargez la spécification VHD.

Conformité logicielle pour Windows

Si votre demande d’image Windows est rejetée en raison d’un problème de conformité logicielle, il se peut que vous avez créé une image Windows avec une instance SQL Server installée. Au lieu de cela, vous devez prendre l’image de base de version SQL Server appropriée à partir de Place de marché Azure.

Ne créez pas d’image Windows dotée de SQL Server. Utilisez les images de base SQL Server approuvées (Entreprise/Standard/Web) provenant de Place de marché Azure.

Si vous essayez d'installer Visual Studio ou un produit sous licence Office, contactez l'équipe du support technique pour obtenir une approbation préalable.

Pour plus d’informations sur la sélection d’une base approuvée, consultez Créer une machine virtuelle à partir d’une base approuvée.

échec de l’exécution du cas de test Shared Computer Toolkit

Le kit de ressources de certification Microsoft peut vous aider à exécuter des cas de test et à vérifier que votre disque dur virtuel ou votre image est compatible avec l'environnement Azure.

Téléchargez le kit de ressources de certification Microsoft.

Cas de test Linux

Le tableau suivant répertorie les cas de test Linux exécutés par le kit de ressources. La validation de test est indiquée dans la description.

Scénario Cas de test Description
1 Historique Bash Les fichiers d'historique Bash doivent être effacés avant la création de l'image de machine virtuelle.
2 Version de l'agent Linux La version minimale prise en charge de l’agent Linux Azure, ou une version ultérieure, doit être installée.
3 Paramètres de noyau requis Vérifie que les paramètres de noyau suivants sont définis :
console=ttyS0
earlyprintk=ttyS0
4 Partition d'échange sur le disque du système d'exploitation Vérifie qu’aucune partition d’échange n’est créée sur le disque du système d’exploitation.
5 Partition racine sur le disque du système d'exploitation Créez une partition racine unique pour le disque de système d’exploitation.
6 Version d'OpenSSL OpenSSL version 0.9.8 ou ultérieure doit être installé.
7 Version Python Python version 2.6 ou ultérieure est fortement recommandé.
8 Intervalle d’activité du client Affectez la valeur 180 à ClientAliveInterval. Pour les besoins de l'application, vous pouvez affecter une valeur comprise entre 30 et 235. Si vous activez le protocole SSH pour vos utilisateurs finaux, cette valeur doit être définie comme expliqué.
9 Architecture du système d’exploitation Seuls les systèmes d’exploitation 64 bits sont pris en charge.
10 Mise à jour automatique Indique si la mise à jour automatique de l’agent Linux est activée.

Erreurs courantes de cas de test

Reportez-vous au tableau suivant pour connaître les erreurs courantes que vous pouvez rencontrer lors de l’exécution de cas de test :

Scénario Cas de test Error Solution
1 Cas de test Version de l'agent Linux La version minimale prise en charge de l’agent Linux Azure, ou une version ultérieure, doit être installée.](https://learn.microsoft.com/troubleshoot/azure/virtual-machines/support-extensions-agent-version) Mettez à jour la version de l’agent Linux. Pour plus d’informations, consultez la page de mise à jour de la version de l’agent Linux.
2 Cas de test Historique Bash Une erreur se produit si la taille de l’historique Bash de l’image que vous avez envoyée est supérieure à 1 kilo-octet (ko). La taille est limitée à 1 ko pour garantir que votre fichier d’historique Bash ne contient pas d’informations potentiellement sensibles. Résolvez l’erreur en montant le disque dur virtuel sur une autre machine virtuelle opérationnelle et apportez des modifications pour réduire la taille à 1 ko ou moins. Par exemple, supprimez les fichiers .bash_history.
3 Cas de test Paramètres de noyau requis Vous recevrez cette erreur lorsque la valeur pour console laquelle la valeur n’est pas définie ttyS0sur . Vérifiez en exécutant la commande suivante :
cat /proc/cmdline
Définissez la valeur pour consolettyS0, puis soumettez à nouveau la requête.
4 Cas de test Intervalle d'activité du client Si le résultat du kit de ressources est un échec pour ce cas de test, cela signifie que la valeur de ClientAliveInterval est incorrecte. Définissez la valeur pour ClientAliveInterval une valeur inférieure ou égale à 235, puis soumettez à nouveau la requête.
5 smoke_test Vous recevrez une erreur lorsque l’image ne peut pas démarrer ou redémarrer en raison d’une panique du noyau. Vous pouvez obtenir des informations de suivi des appels de la panique du noyau à partir de la « description de l’erreur ». Si vous souhaitez voir la trace d’appel entière et le journal série, vous pouvez déployer une machine virtuelle dans Azure à l’aide de votre image et case activée la « console série » dans votre ressource de machine virtuelle dans le Portail Azure. Lorsque vous créez une machine virtuelle dans Azure, vous pouvez télécharger le journal de la console série à partir du Portail Azure (pour https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-linux plus d’informations sur la console série)
6 verify_dns_name_resolution Ce cas de test case activée la résolution de noms DNS en exécutant command :ping bing.com -c 5 -i 0.5 -O. Une erreur se produit si elle ne parvient pas à effectuer un test ping sur une adresse web publique « bing.com ». Reportez-vous à l’ajout https://learn.microsoft.com/en-us/azure/virtual-machines/linux/azure-dns des paramètres appropriés
7 verify_no_pre_exist_users Vous recevrez l’erreur « Mot de passe de l’utilisateur XXXX est détecté » lorsque le mot de passe d’un utilisateur a été détecté ou lorsque la clé d’un utilisateur a été détectée case activée fichier /etc/shadow pour voir s’il a un mot de passe d’un utilisateur, le cas échéant, vous devez supprimer le mot de passe et supprimer le fichier « répertoire de base de {utilisateur}/.ssh/authorized_keys » suivant le message d’erreur
8 validate_netvsc_reload L’erreur « échec » s’affiche. SSHException : session SSH non active. si la machine virtuelle ne peut pas être connectée après l’exécution de la commande ci-dessous. L’erreur « détection de la panique du noyau à partir du nœud de xx » s’affiche. s’il existe une panique du noyau trouvée à partir de la machine virtuelle après avoir exécuté la commande : ' modprobe -r hv_netvsc ; modprobe hv_netvsc ; ip link set eth0 down ; ip link set eth0 up ; dhclient -r eth0 ; dhclient eth0 ' Vérifiez la console série pour voir si une erreur s’est produite pendant la période d’exécution de la commande ci-dessus. https://learn.microsoft.com/en-us/windows-hardware/drivers/network/sr-iov-synthetic-data-path Pour plus d’informations sur le client de service virtuel réseau (NetVSC).

Cas de test Windows

Le tableau suivant répertorie les cas de test Windows exécutés par le kit de ressources, ainsi qu’une description de la validation de test :

Scénario Cas de test Description
1 Architecture du système d’exploitation Azure prend uniquement en charge les systèmes d'exploitation 64 bits.
2 Dépendance de compte d’utilisateur L'exécution de l'application ne doit pas dépendre du compte d'administrateur.
3 Cluster de basculement La fonctionnalité de clustering de basculement Windows Server n'est pas encore prise en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
4 IPV6 Le protocole IPv6 n’est pas encore pris en charge dans l’environnement Azure. L’application ne doit pas être dépendante de cette fonctionnalité.
5 DHCP Le rôle serveur DHCP (Dynamic Host Configuration Protocol) n’est pas encore pris en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
6 Accès à distance Le rôle serveur Accès à distance (Accès direct) n’est pas encore pris en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
7 Rights Management Services Rights Management Services. Le rôle serveur n’est pas encore pris en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
8 Windows Deployment Services Services de déploiement Windows. Le rôle serveur n’est pas encore pris en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
9 Chiffrement de lecteur BitLocker Le chiffrement de lecteur BitLocker n'est pas pris en charge sur le disque dur du système d'exploitation, mais peut être utilisé sur les disques de données.
10 Serveur de nom de stockage Internet La fonctionnalité Serveur de nom de stockage Internet n'est pas encore prise en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
11 MPIO (Multipath I/O) MPIO (Multipath I/O). Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
12 Network Load Balancing Équilibrage de charge réseau. Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
13 Protocole PNRP Protocole PNRP. Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
14 Services SNMP La fonctionnalité Services SNMP n'est pas encore prise en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
15 Windows Internet Name Service Service WINS (Windows Internet Name Service). Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas être dépendante de cette fonctionnalité.
16 Service de réseau local sans fil Service de réseau local sans fil. Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas être dépendante de cette fonctionnalité.

Si vous observez des échecs avec les cas de test précédents, consultez la colonne Description du tableau pour connaître la solution. Pour plus d’informations, contactez l’équipe du support technique.

Vérification de la taille du disque de données

Les demandes de disques de données d’une taille supérieure à 1023 gigaoctets (Go) ne sont pas approuvées. Cette règle s'applique à la fois à Linux et à Windows.

Renvoyez la demande avec une taille inférieure ou égale à 1023 Go.

Validation de la taille du disque du système d’exploitation

Pour plus d’informations sur les limitations relatives à la taille du disque du système d’exploitation, consultez les règles suivantes. Quand vous envoyez une demande, vérifiez que la taille du disque du système d’exploitation est comprise dans les limites de Linux ou de Windows.

Système d’exploitation Taille de disque dur virtuel recommandée
Linux 1 à 1023 Go
Windows 30 à 250 Go

Comme les machines virtuelles autorisent l’accès au système d’exploitation sous-jacent, assurez-vous que la taille du disque dur virtuel est suffisamment grande pour le disque dur virtuel. Les disques ne sont pas extensibles sans temps d’arrêt. Utilisez une taille de disque comprise entre 30 Go et 50 Go.

Taille de disque dur virtuel Taille réelle occupée Solution
>500 tébioctets (Tio) n/a Contactez l'équipe du support technique pour obtenir une approbation d'exception.
250 à 500 Tio >200 gibioctets (Gio) de différence par rapport à la taille de l’objet blob Contactez l'équipe du support technique pour obtenir une approbation d'exception.

Remarque

Les tailles de disque supérieures entraînent des coûts plus élevés et entraînent un retard pendant le processus d’installation et de réplication. En raison de ce retard et de ce coût, l'équipe du support technique est susceptible de demander la justification de l'approbation d'exception.

Test de vérification des correctifs WannaCry pour Windows

Pour prévenir toute attaque liée au virus WannaCry, veillez à ce que toutes les demandes d'image Windows soient mises à jour avec le correctif le plus récent.

Vous pouvez vérifier la version du fichier image à partir de C:\windows\system32\drivers\srv.sys ou srv2.sys.

Le tableau suivant présente la version corrigée minimale de Windows Server :

Système d''exploitation 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 NA

Remarque

Aucune spécification de version obligatoire ne s'applique à Windows Server 2019.

Vérification des correctifs de vulnérabilité SACK

Lorsque vous envoyez une image Linux, votre demande peut être rejetée en raison de problèmes liés à la version du noyau.

Mettez à jour le noyau avec une version approuvée et renvoyez la demande. Vous trouverez la version du noyau approuvée dans le tableau suivant. Le numéro de version doit être supérieur ou égal à celui indiqué ici.

Si votre image n'est pas installée avec l'une des versions de noyau suivantes, mettez-la à jour avec les correctifs appropriés. Demandez l'approbation nécessaire à l'équipe du support technique une fois que l'image a été mise à jour avec les correctifs requis suivants :

  • CVE-2019-11477
  • CVE-2019-11478
  • CVE-2019-11479
Famille de système d’exploitation Version Noyau
Ubuntu 14.04 LTS 4.4.0-151
14.04 LTS 4.15.0-1049-*-azure
LTS 16.04 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 et 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 À définir
RHEL-SAP 7.5 À définir
SLES SLES11SP4 (y compris SAP) 3.0.101-108.95.2
SLES12SP1 pour SAP 3.12.74-60.64.115.1
SLES12SP2 pour SAP 4.4.121-92.114.1
SLES12SP3 4.4180-4.31.1 (noyau-Azure)
SLES12SP3 pour SAP 4.4.180-94.97.1
SLES12SP4 4.12.14-6.15.2 (noyau-Azure)
SLES12SP4 pour SAP 4.12.14-95.19.1
SLES15 4.12.14-5.30.1 (noyau-Azure)
SLES15 pour SAP 4.12.14-5.30.1 (noyau-Azure)
SLES15SP1 4.12.14-5.30.1 (noyau-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 suit RHEL ci-dessus
7.6 RHCK 3.10.0-957.21.3
UEK5 4.14.35-1902.2.0
CoreOS Stable 2079.6.0 4.19.43*
Bêta 2135.3.1 4.19.50*
Alpha 2163.2.1 4.19.50*
Debian jessie (sécurité) 3.16.68-2
jessie (rétroportage) 4.9.168-1+deb9u3
stretch (sécurité) 4.9.168-1+deb9u3
Debian GNU/Linux 10 (buster) Debian 6.3.0-18+deb9u1
buster, sid (rétroportage stretch) 4.19.37-5

La taille de l’image doit être en plusieurs mégaoctets

La taille virtuelle de tous les disques durs virtuels exécutés sur Azure doit être alignée sur des multiples de 1 mégaoctet (Mo). Si votre disque dur virtuel n’est pas conforme à la taille virtuelle recommandée, votre demande peut être rejetée.

Suivez les instructions lors de la conversion d’un disque brut en disque dur virtuel. Assurez-vous que la taille du disque brut est un multiple de 1 Mo. Pour plus d’informations, consultez Informations pour les distributions non-endées.

Accès aux machines virtuelles refusé

Un problème d’accès refusé lié à l’exécution d’un cas de test sur la machine virtuelle peut être dû à des privilèges insuffisants.

Vérifiez que vous avez activé l’accès approprié pour le compte sur lequel les cas d’auto-test sont exécutés. Activez l’accès pour exécuter des cas de test si ce n’est pas le cas. Si vous ne souhaitez pas activer l'accès, vous pouvez partager les résultats de l'auto-test avec l'équipe du support technique.

Pour envoyer votre demande avec une image désactivée SSH pour le processus de certification :

  1. Exécutez l’outil de test de certification le plus récent pour les machines virtuelles Azure sur votre image.

  2. Soumettez un ticket de support. Veillez à joindre le rapport du kit d’outils et fournissez les détails de l’offre :

    • Nom de l’offre
    • nom de l’éditeur ;
    • ID/SKU du plan et version
  3. Soumettez à nouveau votre demande de certification.

Remarque

Si vous publiez une image de machine virtuelle verrouillée qui a désactivé ou restreint ssh, activez le case activée box « Bureau à distance ou SSH désactivé » dans la page « Configuration technique » de l’Espace partenaires. Cela informe l’équipe de certification qu’elle est en cours de conception et effectue les validations appropriées sur l’image sans l’avoir échoué pour un accès restreint.

Locked-down checkbox

Échec du téléchargement

Reportez-vous au tableau suivant pour tout problème survenant lorsque vous téléchargez l’image de machine virtuelle à l’aide d’une URL de signature d’accès partagé (SAP).

Erreur Motif Solution
Objet blob introuvable Le disque dur virtuel a peut-être été supprimé ou déplacé de l'emplacement spécifié.
Objet blob en cours d'utilisation Le disque dur virtuel est utilisé par un autre processus interne. Le stockage blob source du disque dur virtuel est modifié pendant la publication. Le disque dur virtuel ne doit pas être dans un état utilisé lorsque vous le téléchargez avec une URL SAP. En outre, n’utilisez pas/ne modifiez pas le disque dur virtuel lorsque la publication est en cours.
URL SAS non valide L'URL de signature d'accès partagé associée au disque dur virtuel est incorrecte. Récupérez l’URL SAS correcte.
Signature incorrecte L'URL de signature d'accès partagé associée au disque dur virtuel est incorrecte. Récupérez l’URL SAS correcte.
En-tête HTTP conditionnel L'URL de signature d'accès partagé n'est pas valide. Récupérez l’URL SAS correcte.
Nom de disque dur virtuel non valide Recherchez la présence de caractères spéciaux, comme un signe de pourcentage % ou des guillemets " dans le nom du disque dur virtuel. Renommez le fichier VHD en supprimant les caractères spéciaux.

Les images de machine virtuelle doivent avoir 1 Mo d’espace libre

Si vous publiez votre image sur Azure (avec la partition GPT), nous vous recommandons vivement de conserver les 2 048 premiers secteurs (1 Mo) du disque du système d’exploitation vide. Cette exigence vise à permettre à Azure d’ajouter des métadonnées importantes à l’image (par exemple, des métadonnées destinées à améliorer le temps de démarrage pour les clients, la facturation et d’autres détails). Il s’agit d’une recommandation pour la bonne pratique si vous utilisez déjà une image de base approuvée et que votre image a une balise de facturation valide. Toutefois, si votre image n’a pas de balise de facturation valide, votre publication peut échouer si la première Mo du disque du système d’exploitation n’est pas vide.

Si vous créez votre propre image qui n’a pas de balise de facturation valide, vérifiez que les 2 048 premiers secteurs (1 Mo) du disque du système d’exploitation sont vides. Sinon, votre publication échouera. Cette exigence ne s’applique qu’au disque de système d’exploitation (et non aux disques de données). Si vous créez votre image à partir d’une base approuvée, elle aura déjà 1 Mo vide. Vous n’aurez donc pas besoin de travailler dessus séparément.

Pour conserver le premier Mo d’espace libre sur votre disque de système d’exploitation, procédez comme décrit dans la section suivante.

Comment conserver 1 Mo d’espace libre au démarrage sur un disque dur virtuel vide (2 048 secteurs, de 512 octets chacun)

Ces étapes s’appliquent uniquement à Linux.

  1. Créez n’importe quel type de machine virtuelle Linux (par exemple Ubuntu, CentOS ou autre). Renseignez les champs obligatoires, puis sélectionnez Suivant : Disques.

    Screenshot that shows the Create a virtual machine page with the Next: Disks command button highlighted.

  2. Créez un disque non managé pour votre machine virtuelle. Utilisez les valeurs par défaut ou spécifiez une valeur pour les champs tels que la taille du disque de système d’exploitation, le type de disque de système d’exploitation et le type de chiffrement.

    Screenshot image of the Data disks page in the Create a virtual machine flow.

  3. Après avoir créé la machine virtuelle, sélectionnez Disques dans le volet gauche.

    Screenshot showing how to select disks for a V M.

  4. Attachez votre disque dur virtuel à votre machine virtuelle en tant que disque de données pour créer la table de partition.

    1. Sélectionnez Attacher des disques existants :

      Screenshot showing how to add a data disk to your V H D.

      Screenshot showing how to select the data disk for your V H D.

    2. Recherchez votre compte de stockage VHD.

    3. Sélectionnez Conteneur, puis votre disque dur virtuel.

    4. Cliquez sur OK.

      Screenshot of the attach unmanaged disk page.

      Votre disque dur virtuel sera ajouté en tant que disque de données LUN 0.

  5. Redémarrez la machine virtuelle.

  6. Après avoir redémarré la machine virtuelle, connectez-vous à celle-ci à l’aide de Putty ou d’un autre client et exécutez la commande sudo -i pour obtenir un accès racine.

    Putty client command-line screenshot showing the sudo -i command.

  7. Créez une partition sur votre disque dur virtuel.

    1. Entrez la commande fdisk /dev/sdb.

    2. Pour afficher la liste des partitions existantes de votre disque dur virtuel, entrez p.

    3. Entrez d pour supprimer toutes les partitions existantes disponibles dans votre disque dur virtuel. Vous pouvez ignorer cette étape si elle n’est pas nécessaire.

      Putty client command-line screenshot showing the commands for deleting existing partitions.

    4. Entrez n pour créer une nouvelle partition et sélectionnez p pour (partition principale).

    5. Entrez 2048 comme valeur de premier secteur. Vous pouvez conserver dernier secteur comme valeur par défaut.

      Important

      Toutes les données existantes sont effacées jusqu’à 2 048 secteurs (de 512 octets chacun). Sauvegardez le disque dur virtuel avant de créer une nouvelle partition.

      Putty client command-line screenshot showing the commands and output for erased data.

    6. Entrez w pour confirmer la création de la partition.

      Putty client command-line screenshot showing the commands for creating a partition.

    7. Vous pouvez vérifier la table de partition en exécutant la commande n fdisk /dev/sdb et en saisissant p. Vous verrez que la partition est créée avec une valeur de décalage de 2048.

      Putty client command-line screenshot showing the commands for creating the 2048 offset.

  8. Détachez le disque dur virtuel de la machine virtuelle et supprimez la machine virtuelle.

Informations d’identification par défaut

N’envoyez jamais d’informations d’identification par défaut avec le disque dur virtuel soumis. L’ajout d’informations d’identification par défaut rend le VHD plus vulnérable aux menaces de sécurité. Au lieu de cela, créez vos propres informations d'identification lors de l'envoi du disque dur virtuel.

DataDisk mappé de manière incorrecte

Un problème de mappage peut se produire lorsqu’une demande est envoyée avec plusieurs disques de données qui ne sont pas en séquence. Par exemple, l’ordre de numérotation pour trois disques de données doit être 0, 1, 2. Tout autre ordre sera traité comme un problème de mappage.

Renvoyez la demande avec un séquencement approprié des disques de données.

Mappage de système d’exploitation incorrect

Lorsqu'une image est créée, elle peut être mappée ou attribuée à une étiquette de système d'exploitation incorrecte. Par exemple, lorsque vous sélectionnez Windows comme partie du nom du système d'exploitation lors de la création de l'image, le disque du système d'exploitation doit uniquement être installé avec Windows. La même exigence s'applique à Linux.

Machine virtuelle non généralisée

Si toutes les images issues de la Place de marché Azure doivent être réutilisées, le disque dur virtuel du système d'exploitation doit être généralisé.

  • Pour Linux, le processus suivant généralise une machine virtuelle Linux et la redéploie sous la forme d'une machine virtuelle distincte.

    Dans la fenêtre SSH, entrez la commande suivante : sudo waagent -deprovision+user.

  • Pour Windows, vous pouvez généraliser les images Windows à l'aide de sysreptool.

    Pour plus d’informations sur l’outil sysreptool, consultez Présentation de l’outil de préparation système (Sysprep).

Erreurs DataDisk

Pour remédier aux erreurs liées au disque de données, utilisez le tableau suivant :

Erreur Motif Solution
DataDisk- InvalidUrl: Cette erreur peut survenir lorsqu’un numéro d’unité logique (LUN) non valide lors de l’envoi de l’offre. Vérifiez que la séquence de numéros d'unités logiques du disque de données figure dans l'Espace partenaires.
DataDisk- NotFound: Cette erreur peut survenir lorsqu’un disque de données ne se trouve pas à l’URL de signature d’accès partagé spécifiée. Vérifiez que le disque de données se trouve à l’URL de signature d’accès partagé spécifiée.

Problème d’accès à distance

Vous obtiendrez cette erreur si l’option RDP (Remote Desktop Protocol) n’est pas activée pour l’image Windows.

Activez l'accès RDP pour les images Windows avant de les envoyer.

Échec de l’historique Bash

Vous obtiendrez cette erreur si la taille de l’historique Bash de l’image que vous avez envoyée est supérieure à 1 kilooctet (ko). La taille est limitée à 1 ko pour empêcher le fichier de contenir des informations potentiellement sensibles.

Pour supprimer l’historique Bash :

  1. Déployez la machine virtuelle et sélectionnez l’option Run Command sur le portail Azure.

    Screenshot of the Azure portal with the 'Run Command' option in the left pane.

  2. Sélectionnez la première option RunShellScript, puis exécutez la commande cat /dev/null > ~/.bash_history && history -c.

    Screenshot of 'Run Command Script' page on the Azure portal.

  3. Une fois la commande exécutée, redémarrez la machine virtuelle.

  4. Généralisez la machine virtuelle, prenez l’image du disque dur virtuel et arrêtez la machine virtuelle.

  5. Soumettez à nouveau l’image généralisée.

Validations de l’appliance virtuelle réseau

Pendant la certification d’image de la Place de marché, une offre de machine virtuelle qui est une appliance virtuelle réseau (NVA) est validée à l’aide de tests génériques pour n’importe quelle offre de machine virtuelle et des cas de test NVA répertoriés dans le tableau ci-dessous. L’objectif de ces validations spécifiques d’appliance virtuelle réseau est de vérifier la manière dont l’image d’appliance virtuelle réseau orchestre avec la pile SDN.

Cas de test Étapes à suivre pour exécuter un cas de test Solution
Accès au disque dur virtuel (VHD) Vérifiez que l’URL SAS correcte pour le VHD est fournie, que les autorisations sont définies pour autoriser l’accès, et que l’image d’appliance virtuelle réseau est généralisée. Vérifiez l’image d’appliance virtuelle réseau et l’URL fournies.
Déploiement d’appliance virtuelle réseau Déployez une machine virtuelle à l’aide de l’appliance virtuelle réseau avec une seule carte réseau. Vérifiez que le déploiement est accompli en 20 minutes. Si le déploiement n’est pas terminé dans les 20 minutes, vérifiez l’image NVA.
Redémarrage de appliance virtuelle réseau Déployez une machine virtuelle à l’aide de l’appliance virtuelle réseau avec une seule carte réseau. Ensuite, accédez à la machine virtuelle dans Portail Azure, puis, sous la section Support + résolution des problèmes dans le volet gauche, sélectionnez Redéployer + Réappliquer et redéployer la machine virtuelle. Une fois le redéploiement terminé, vérifiez que l’état de la machine virtuelle est En cours d’exécution et que le port de carte réseau 22 est accessible à l’aide de la commande Netcat. Si la machine virtuelle n’apparaît pas après le redémarrage, il peut y avoir un problème avec l’image NVA.

Si le test Netcat échoue, cela peut être dû au fait que la carte réseau n’a pas été réactivée après le redémarrage, même si la machine virtuelle était en cours d’exécution. Attendez quelques minutes et réessayez. Si, après 20 minutes, elle échoue toujours, il peut y avoir un problème avec l’image NVA
Redéploiement d’appliance virtuelle réseau Déployez une machine virtuelle à l’aide de l’appliance virtuelle réseau avec une seule carte réseau. Ensuite, redéployez la machine virtuelle. Vérifiez que l’état de la machine virtuelle est En cours d’exécution et que le port de carte réseau 22 est accessible à l’aide de la commande Netcat. Si le redéploiement ne se termine pas dans les 15 minutes, il peut y avoir un problème avec l’image NVA.

Si le test Netcat échoue, cela peut être dû au fait que la carte réseau n’a pas été réactivée après le redémarrage, même si la machine virtuelle était en cours d’exécution. Attendez quelques minutes et réessayez. Si, après 20 minutes, elle échoue toujours, il peut y avoir un problème avec l’image NVA
Haute disponibilité Déployez une machine virtuelle à l’aide de l’appliance virtuelle réseau avec une seule carte réseau. Aucune adresse IP publique ne doit être attachée à la carte réseau ou, si une adresse IP publique est attachée, la référence SKU doit être standard et la méthode d’allocation d’adresse IP doit être statique. Dans le même réseau virtuel, configurez un équilibreur de charge interne Azure à l’aide de la configuration ci-dessous.
- Équilibreur de charge utilisant une référence SKU standard
- Adresse IP frontale utilisant une méthode d’allocation d’adresse IP privée comme dynamique
- Sondes d’intégrité utilisant le protocole TCP, sur le port 22, avec un intervalle de nouvelle tentative de 15 secondes
- Règle d’équilibrage de charge avec le protocole all et activer l’adresse IP flottante définie sur False.
- Pool principal pointant sur la machine virtuelle d’appliance virtuelle réseau.

Une fois la configuration prête, vérifiez que la machine virtuelle d’appliance virtuelle réseau est accessible à travers l’équilibreur de charge à l’aide de la commande Netcat.
Si l’appliance virtuelle réseau est inaccessible dans l’équilibreur de charge, vérifiez la configuration de la machine virtuelle, de l’équilibreur de charge et de la fonctionnalité des ports haute disponibilité. Si tout est précis, il peut y avoir un problème avec l’image de l’appliance virtuelle réseau.
VNET Peering Déployez une machine virtuelle VM1 à l’aide de l’image NVA, avec une carte réseau dans un réseau virtuel VNET1. Dans un autre réseau virtuel VNET2, déployez une machine virtuelle VM2 à l’aide d’une image Linux, par exemple ubuntu, avec une carte réseau et des paramètres de machine virtuelle en tant que méthode d’allocation IP dynamique et référence SKU de base. Créez un appairage de réseaux virtuels entre les réseaux VNET1 et VNET2, et configurez le Trafic vers le réseau virtuel distant sur Autoriser (par défaut)

Une fois la configuration prête, vérifiez que à partir de la machine virtuelle VM2, nous pouvons atteindre l’adresse IP privée de la carte réseau sur l’appliance virtuelle réseau VM1, à l’aide de la commande Netcat.
Si l’appliance virtuelle réseau VM1 est inaccessible à partir de la machine virtuelle VM2, vérifiez que l’appairage de réseaux virtuels est correctement configuré, puis réessayez. S’il ne fonctionne toujours pas, il peut y avoir un problème avec l’image NVA.
Mise en réseau accélérée Déployez une machine virtuelle avec l’appliance virtuelle réseau et 1 carte réseau activée pour la mise en réseau accélérée. Vous pouvez activer la mise en réseau accélérée sur une carte réseau lors de la création de la machine virtuelle ou sur les propriétés de la carte réseau après création de la machine virtuelle. Vérifiez que la machine virtuelle sera opérationnelle. Si le déploiement échoue, vérifiez que l’image NVA prend en charge la mise en réseau accélérée.
Référence SKU de base avec plusieurs cartes réseau Déployez une machine virtuelle en utilisant l’appliance virtuelle réseau avec 3 cartes réseau, avec la méthode d’allocation d’adresse IP dynamique et une référence SKU de base. Obtenez des adresses IP privées et MAC pour toutes les cartes réseau (pour obtenir des instructions, consultez Afficher les paramètres d’interface réseau). Ensuite, redéployez la machine virtuelle, puis vérifiez que les adresses IP privées et MAC de toutes les cartes réseau sont les mêmes qu’avant le redéploiement. Si l’adresse IP privée et MAC de toutes les cartes réseau change après le redéploiement, il peut y avoir un problème avec l’image NVA.
Interruption de réseau Déployez une machine virtuelle à l’aide de l’appliance virtuelle réseau avec une seule carte réseau. Ensuite, créez et appliquez un groupe de sécurité réseau (NSG) pour bloquer tout le trafic vers la machine virtuelle d’appliance virtuelle réseau. Ensuite, vérifiez que l’état de la machine virtuelle est En cours d’exécution. Si, après l’application du groupe de sécurité réseau, la machine virtuelle tombe en panne, il peut y avoir un problème avec l’image de l’appliance virtuelle réseau.

Pour plus d’informations ou de questions, ouvrez un cas de support Azure.

Vue d’ensemble de Netcat :

Netcat est une commande capable d’établir une connexion TCP ou UDP entre deux ordinateurs, ce qui signifie qu’elle peut écrire et lire via un port ouvert. Pendant les validations de l’appliance virtuelle réseau, nous exécutons la commande Netcat à partir d’une machine virtuelle qui se trouve dans le même réseau virtuel que la machine virtuelle NVA pour tester si le port TCP 22 est accessible. La syntaxe de la commande est nc <destination_ip_address> <destination_port>

  • destination_ip_address est l’adresse IP privée attribuée à la carte réseau de machine virtuelle,
  • destination_port est le numéro de port sur l’appliance virtuelle réseau. Nous utilisons 22 dans les cas de test d’appliance virtuelle réseau.

Par exemple, nc 192.168.1.1 22

Demander une exception sur les images de machine virtuelle pour sélectionner des tests

Les éditeurs peuvent demander des exceptions pour quelques tests effectués pendant la certification de la machine virtuelle. Des exceptions sont prévues dans de rares cas lorsqu’un éditeur fournit des preuves à l’appui de la demande. L’équipe de certification se réserve le droit de refuser ou d’approuver des exceptions à tout moment.

Cette section décrit les scénarios généraux dans lesquels les éditeurs demandent une exception et la façon d’en demander une.

Scénarios pour une exception

Les éditeurs demandent généralement des exceptions dans les cas suivants :

  • Exception pour un ou plusieurs cas de test. Contactez le support d’Espace partenaires pour demander des exceptions pour des cas de test.

  • Machines virtuelles verrouillées/aucun accès racine. Quelques éditeurs ont des scénarios dans lesquels les machines virtuelles doivent être verrouillées, car des logiciels tels que des pare-feu sont installés sur la machine virtuelle. Dans ce cas, téléchargez l’outil de test certifié et envoyez le rapport au support d’Espace partenaires.

  • Modèles personnalisés. Certains éditeurs publient des images de machine virtuelle qui nécessitent un modèle Azure Resource Manager personnalisé pour déployer les machines virtuelles. Dans ce cas, envoyez les modèles personnalisés au support de l’Espace partenaires à utiliser par l’équipe de certification pour validation.

Informations à fournir pour les scénarios d’exception

Contactez le support d’Espace partenaires pour demander une exception pour l’un des scénarios et incluez les informations suivantes :

  • ID de l’éditeur. Saisissez votre ID d’éditeur sur le portail Espace partenaires.

  • ID/nom d’offre. Entrez l’ID ou le nom de l’offre.

  • ID/SKU du plan. Saisissez l’ID ou la référence SKU du plan de l’offre de machine virtuelle.

  • Version. Entrez la version de l’offre de machine virtuelle qui requiert une exception.

  • Type d’exception. Choisissez parmi les tests, les machines virtuelles verrouillées ou les modèles personnalisés.

  • Motif de la demande. Incluez la raison de la demande d’exception, ainsi que toutes les informations sur les exemptions de test.

  • Chronologie. Entrez la date de fin de l’exception.

  • Pièce jointe. Documents de preuve importants joints :

    • Pour les machines virtuelles verrouillées, joignez le rapport de test.
    • Pour les modèles personnalisés, fournissez le modèle Resource Manager personnalisé en pièce jointe.

    Si vous ne les joignez pas, votre demande sera refusée.

Résoudre une vulnérabilité ou une attaque dans une offre de machine virtuelle

Cette décrit comment fournir une nouvelle image de machine virtuelle quand une vulnérabilité ou un code malveillant exploitant une faille de sécurité est détecté dans l’une de vos images de machine virtuelle. Elle s’applique uniquement aux offres de machine virtuelle Azure publiées sur Place de marché Azure.

Remarque

Vous ne pouvez pas supprimer la dernière image de machine virtuelle d’un plan ni arrêter la vente du dernier plan d’une offre.

Effectuez l’une des actions suivantes :

Fournir une image de machine virtuelle corrigée

Pour fournir une image de machine virtuelle corrigée afin de remplacer une image de machine virtuelle qui présente une vulnérabilité ou un code malveillant exploitant une faille de sécurité :

  1. Fournissez une nouvelle image de machine virtuelle pour résoudre la vulnérabilité ou le code malveillant exploitant une faille de sécurité.
  2. Supprimez l’image de machine virtuelle présentant la vulnérabilité de sécurité ou le code malveillant exploitant une faille de sécurité.
  3. Republiez l’offre.

Fournir une nouvelle image de machine virtuelle pour résoudre la vulnérabilité ou le code malveillant exploitant une faille de sécurité

Pour effectuer ces étapes, préparez les ressources techniques pour l’image de machine virtuelle que vous souhaitez ajouter. Pour plus d’informations, consultez Création d’une machine virtuelle avec une base approuvée ou Création d’une machine virtuelle avec votre propre image et Génération d’un URI SAS pour une image de machine virtuelle.

  1. Connectez-vous à l’Espace partenaires.

  2. Sur la page d’accueil, sélectionnez la vignette Offres de la Place de marché.

  3. Dans la colonne Alias de l’offre, sélectionnez l’offre.

  4. Sélectionnez l’onglet Vue d’ensemble du plan, puis sélectionnez le plan approprié.

  5. Sous l’onglet Configuration technique, sous Images de machine virtuelle, sélectionnez + Ajouter une image de machine virtuelle.

    Remarque

    Vous ne pouvez ajouter à un plan qu’une seule image de machine virtuelle à la fois. Pour ajouter plusieurs images de machine virtuelle, publiez la première avant d’ajouter l’image de machine virtuelle suivante.

  6. Dans les zones qui s’affichent, indiquez une nouvelle version du disque et l’image de la machine virtuelle.

  7. Sélectionnez Enregistrer le brouillon.

Ensuite, supprimez l’image de machine virtuelle présentant la vulnérabilité de sécurité.

Supprimer l’image de machine virtuelle présentant la vulnérabilité de sécurité ou le code malveillant exploitant une faille de sécurité

  1. Connectez-vous à l’Espace partenaires.
  2. Sur la page d’accueil, sélectionnez la vignette Offres de la Place de marché.
  3. Dans la colonne Alias de l’offre, sélectionnez l’offre.
  4. Sélectionnez l’onglet Vue d’ensemble du plan, puis sélectionnez le plan approprié.
  5. Sous l’onglet Configuration technique, sous Images de machine virtuelle, à côté de l’image de machine virtuelle que vous souhaitez supprimer, sélectionnez Supprimer une image de machine virtuelle.
  6. Dans la boîte de dialogue, sélectionnez Continuer.
  7. Sélectionnez Enregistrer le brouillon.

Ensuite, republiez l’offre.

Republier l’offre

  1. Sélectionnez Vérifier et publier.
  2. Si vous avez besoin de fournir des informations à l’équipe de certification, ajoutez-les dans la zone Notes pour la certification.
  3. Sélectionnez Publier.

Pour terminer le processus de publication, consultez Réviser et publier des offres.

Images de machine virtuelle avec accès limité ou nécessitant des modèles personnalisés

Offre SSH désactivé (ou) verrouillé

Les images publiées avec le protocole SSH désactivé (pour Linux) ou le protocole RDP désactivé (pour Windows) sont traitées comme des machines virtuelles verrouillées. Il existe des scénarios métier spéciaux à cause desquels les serveurs de publication n’autorisent qu’un accès restreint à un nombre limité d’utilisateurs voire à aucun.

Lors des contrôles de validation, les machines virtuelles verrouillées risquent de ne pas autoriser l’exécution de certaines commandes de certification.

Modèles personnalisés

En général, toutes les images publiées sous une seule offre de machine virtuelle suivent le modèle ARM standard pour le déploiement. Toutefois, il existe des scénarios dans lesquels le serveur de publication peut exiger une personnalisation lors du déploiement de machines virtuelles (par exemple, plusieurs cartes réseau à configurer).

En fonction des scénarios ci-dessous (non extérieurs), les éditeurs utilisent des modèles personnalisés pour déployer la machine virtuelle :

  • La machine virtuelle nécessite des sous-réseaux réseau supplémentaires.
  • Autres métadonnées à insérer dans le modèle ARM.
  • commandes prérequises pour l’exécution du modèle ARM.

Extensions de machine virtuelle

Les extensions de machine virtuelle Azure sont de petites applications permettant d’exécuter des tâches de configuration et d’automatisation de post-déploiement sur des machines virtuelles Azure. Par exemple, si une machine virtuelle nécessite l’installation d’un logiciel, une protection antivirus ou l’exécution d’un script, vous pouvez utiliser une extension de machine virtuelle.

Les validations de l’extension de machine virtuelle Linux nécessitent que les éléments suivants fassent partie de l’image :

Pour plus d’informations, consultez l’extension de machine virtuelle.

Vérification de l’intégrité de l’image

Si vous créez une image et que vous créez un disque hors de l’image pour vérifier l’intégrité de l’image, notez que la première Mo est réservée aux performances optimisées et que les 512 derniers octets sont réservés au pied de page de disque dur virtuel. Ainsi, ignorez-les lors de la vérification de l’intégrité de l’image.

Étapes suivantes