Lorsque vous publiez votre image de machine virtuelle sur la 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 n’est pas publiée. Vous recevrez un message d’erreur qui décrit le problème.

Cet article explique les messages d’erreur courants lors de la publication d’images de machine virtuelle, ainsi que les solutions associées.

Note

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

Vérifiez 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 aux paramètres de diagnostic .

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

4. Sélectionnez Enregistrer.

   

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

1. Dans la machine virtuelle, sélectionnez l'extensions de machine virtuelle onglet, puis vérifiez l’état de l’extension diagnostics Linux .

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

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

   

   Si l’extension de machine virtuelle échoue, consultez Utiliser l’extension de diagnostic Linux pour surveiller les métriques et les journaux d’activité pour 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.

Vérifiez que vous avez suivi rigoureusement le processus d’approvisionnement des machines virtuelles avant de soumettre votre offre. Pour afficher le format JSON pour l’approvisionnement de la machine virtuelle, consultez Tester une image de machine virtuelle.

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

Scénario	Erreur	Raison	Solution
1	Disque dur virtuel non valide (VHD)	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	L’approvisionnement de machines virtuelles a échoué, car l’objet blob utilisé est un type de bloc au lieu d’un type de page.	Recréez l’image en tant que type de page et envoyez la demande.
3	Délai d’approvisionnement ou non généralisé correctement	Il existe un problème de généralisation des machines virtuelles.	Recréez l’image avec généralisation et envoyez la demande.

Note

Pour plus d’informations sur la généralisation des machines virtuelles, consultez :

• documentation Linux
• documentation Windows

Note

Si l’approvisionnement échoue lorsque l’image de machine virtuelle nécessite un modèle ARM personnalisé à déployer, activez la case à cocher « Exiger un modèle ARM personnalisé pour le déploiement » dans la page « Configuration technique » de l’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.

Spécifications de disque dur virtuel

Cookie Conectix et autres spécifications de disque dur virtuel

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

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

Champs de pied de page de disque dur	Taille (octets)
Biscuit	8
Fonctionnalités	4
Version du format de fichier	4
Décalage des données	8
Horodatage	4
Creator Application	4
Version du créateur	4
Système d’exploitation hôte créateur	4
Taille d’origine	8
Taille actuelle	8
Géométrie de disque	4
Type de disque	4
Somme de contrôle	4
Unique ID	16
État enregistré	1
Réservé	427

Pour garantir une expérience de publication fluide, assurez-vous que votre 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 de l’objet blob de disque dur virtuel est égale à la taille virtuelle plus la longueur du pied de page du disque dur virtuel (512).

Téléchargez la spécification disque dur virtuel.

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 la Place de marché Azure.

Ne créez pas votre propre image Windows avec SQL Server installé dans celui-ci. Utilisez les images de base SQL Server approuvées (Enterprise/Standard/web) à partir de la 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’unde base approuvé.

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 de Bash	Les fichiers d’historique Bash doivent être effacés avant de créer l’image de machine virtuelle.
2	Version de l’agent Linux	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	Permuter une partition sur le disque du système d’exploitation	Vérifie que les partitions d’échange ne sont pas créées 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 du système d’exploitation.
6	Version d’OpenSSL	La version OpenSSL doit être v0.9.8 ou ultérieure.
7	Version de Python	Python version 2.6 ou ultérieure est vivement recommandé.
8	Intervalle actif du client	Définissez ClientAliveInterval sur 180. Sur la demande de l’application, elle peut être définie de 30 à 235. Si vous activez 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	Identifie 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 voir lors de l’exécution de cas de test :

Scénario	Cas de test	Erreur	Solution
1	Cas de test de 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 page de mise à jour de version de l’agent Linux.
2	Cas de test de l’historique Bash	Une erreur se produit si la taille de l’historique Bash dans votre image soumise est supérieure à 1 kilo-octet (Ko). La taille est limitée à 1 Ko pour vous assurer que votre fichier d’historique Bash ne contient aucune information potentiellement sensible.	Résolvez 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 de paramètre de noyau requis	Vous recevrez cette erreur lorsque la valeur de console n’est pas définie sur ttyS0. Vérifiez en exécutant la commande suivante : cat /proc/cmdline	Définissez la valeur de console sur ttyS0, puis soumettez à nouveau la requête.
4	Cas de test d’intervalle ClientAlive	Si le kit de ressources vous donne un résultat défaillant pour ce cas de test, il existe une valeur inappropriée pour ClientAliveInterval.	Définissez la valeur de ClientAliveInterval sur 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 afficher 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 vérifier 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 (vous pouvez vous référer à https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-linux pour plus d’informations sur la console série)
6	verify_dns_name_resolution	Ce cas de test vérifie 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 à https://learn.microsoft.com/en-us/azure/virtual-machines/linux/azure-dns pour ajouter les 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	vérifiez /etc/shadow file 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 « {user’s home directory}/.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 y a 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. Vous pouvez visiter https://learn.microsoft.com/en-us/windows-hardware/drivers/network/sr-iov-synthetic-data-path pour plus d’informations sur Network Virtual Service Client (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 dépendre de cette fonctionnalité.
4	IPV6	IPv6 n’est pas encore pris en charge dans l’environnement Azure. L’application ne doit pas dépendre de cette fonctionnalité.
5	DHCP	Le rôle serveur de protocole de configuration d’hôte dynamique n’est pas encore pris en charge. L’application ne doit pas dépendre 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 dépendre 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 dépendre de cette fonctionnalité.
8	Services de déploiement Windows	Services de déploiement Windows. Le rôle serveur n’est pas encore pris en charge. L’application ne doit pas dépendre 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 il peut être utilisé sur les disques de données.
10	Serveur de noms de stockage Internet	La fonctionnalité Serveur de noms de stockage Internet n’est pas encore prise en charge. L’application ne doit pas dépendre de cette fonctionnalité.
11	E/S multipath	E/S multipath. Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas dépendre de cette fonctionnalité.
12	Équilibrage de charge réseau	Équilibrage de charge réseau. Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas dépendre de cette fonctionnalité.
13	Protocole de résolution de noms d’homologue	Protocole de résolution de noms d’homologue. Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas dépendre de cette fonctionnalité.
14	SNMP Services	La fonctionnalité Services SNMP (Simple Network Management Protocol) n’est pas encore prise en charge. L’application ne doit pas dépendre de cette fonctionnalité.
15	Windows Internet Name Service	Service Windows Internet Name. Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas dépendre de cette fonctionnalité.
16	Service LAN sans fil	Service LAN sans fil. Cette fonctionnalité de serveur n’est pas encore prise en charge. L’application ne doit pas dépendre de cette fonctionnalité.

Si vous rencontrez des échecs avec les cas de test précédents, reportez-vous à la colonne description de la table pour la solution. Pour plus d’informations, contactez l’équipe de support technique.

Les demandes de disque de données dont la taille est supérieure à 1023 gigaoctets (Go) ne seront pas approuvées. Cette règle s’applique à la fois à Linux et à Windows.

Soumettez à nouveau la requête avec une taille inférieure ou égale à 1023 Go.

Reportez-vous aux règles suivantes pour connaître les limitations relatives à la taille du disque du système d’exploitation. Lorsque vous envoyez une demande, vérifiez que la taille du disque du système d’exploitation est limitée pour Linux ou Windows.

OS	Taille de disque dur virtuel recommandée
Linux	1 Go à 1023 Go
Windows	30 Go à 250 Go

Étant donné que 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 du disque dur virtuel	Taille occupée réelle	Solution
>500 tebibytes (Tio)	n/a	Contactez l’équipe du support technique pour obtenir une approbation d’exception.
250-500 Tio	>différence de 200 gibibytes (Gio) par rapport à la taille de l’objet blob	Contactez l’équipe du support technique pour obtenir une approbation d’exception.

Note

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 délai et de ce coût, l’équipe de support peut demander la justification de l’approbation de l’exception.

Pour éviter une attaque potentielle liée au virus WannaCry, assurez-vous que toutes les demandes d’image Windows sont mises à jour avec le dernier correctif.

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

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

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	NA

Note

Windows Server 2019 n’a pas de configuration requise pour la version obligatoire.

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

Mettez à jour le noyau avec une version approuvée et soumettez à nouveau la requête. Vous trouverez la version approuvée du noyau dans le tableau suivant. Le numéro de version doit être égal ou supérieur au nombre répertorié 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 l’image mise à jour avec ces correctifs requis :

• CVE-2019-11477
• CVE-2019-11478
• CVE-2019-11479

Famille de systèmes d’exploitation	Version	Noyau
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
Système d’exploitation RHEL et Cent	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 (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 (kernel-azure)
	SLES12SP3 pour SAP	4.4.180-94.97.1
	SLES12SP4	4.12.14-6.15.2 (kernel-azure)
	SLES12SP4 pour SAP	4.12.14-95.19.1
	SLES15	4.12.14-5.30.1 (kernel-azure)
	SLES15 pour 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 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 backports	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 (étirement backports)	4.19.37-5

Tous les disques durs virtuels sur Azure doivent avoir une taille virtuelle alignée sur plusieurs mégaoctets (Mo). Si votre disque dur virtuel ne respecte pas la taille virtuelle recommandée, votre demande peut être rejetée.

Suivez les instructions lorsque vous convertissez d’un disque brut en disque dur virtuel. Vérifiez que la taille du disque brut est un multiple de 1 Mo. Pour plus d’informations, consultez Informations pour les distributions nonendaires.

Un accès refusé problème d’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 en cours d’exécution. Activez l’accès pour exécuter des cas de test s’il n’est pas activé. Si vous ne souhaitez pas activer l’accès, vous pouvez partager les résultats de cas d’auto-test avec l’équipe du support technique.

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

1. Exécutez dernier outil de test de certification pour les machines virtuelles Azure sur votre image.

2. Déclenchez un ticket de support . Veillez à joindre le rapport du kit de ressources et à fournir les détails de l’offre :

   • Nom de l’offre
   • Nom du serveur de publication
   • ID de plan/référence SKU et version

3. Soumettez à nouveau votre demande de certification.

Note

Si vous publiez une image de machine virtuelle verrouillée qui a désactivé ou restreint ssh, activez la case à cocher « 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.

Reportez-vous au tableau suivant pour connaître les problèmes qui surviennent lorsque vous téléchargez l’image de machine virtuelle avec une URL de signature d’accès partagé (SAP).

Erreur	Raison	Solution
Objet blob introuvable	Le disque dur virtuel peut être supprimé ou déplacé à partir de l’emplacement spécifié.
Objet blob en cours d’utilisation	Le disque dur virtuel est utilisé par un autre processus interne. Le stockage d’objets blob source du disque dur virtuel est modifié lors de 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 SAP non valide	L’URL SAS associée pour le disque dur virtuel est incorrecte.	Obtenez l’URL SAS correcte.
Signature non valide	L’URL SAS associée pour le disque dur virtuel est incorrecte.	Obtenez l’URL SAS correcte.
En-tête conditionnel HTTP	L’URL SAP n’est pas valide.	Obtenez l’URL SAS correcte.
Nom du disque dur virtuel non valide	Vérifiez si des caractères spéciaux, tels qu’un signe de pourcentage % ou des guillemets ", existent dans le nom du disque dur virtuel.	Renommez le fichier de disque dur virtuel en supprimant les caractères spéciaux.

Si vous publiez votre image sur Azure (avec partition GPT), nous vous recommandons vivement de conserver les 2 048 premiers secteurs (1 Mo) du disque du système d’exploitation vides. Cette exigence consiste à permettre à Azure d’ajouter des métadonnées importantes à l’image (par exemple, les métadonnées permettent d’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 étiquette de facturation valide. Toutefois, si votre image n’a pas de balise de facturation valide, votre publication peut échouer si les 1 premiers Mo du disque du système d’exploitation ne sont pas vides.

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 échoue. Cette exigence s’applique uniquement au disque du système d’exploitation (et non aux disques de données). Si vous générez votre image à partir d’une base approuvée, elle aura déjà 1 Mo vides. Par conséquent, vous n’aurez pas besoin de travailler séparément.

Pour libérer les 1 Premiers Mo sur votre disque de système d’exploitation, effectuez les étapes décrites dans la section suivante.

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

Ces étapes s’appliquent uniquement à Linux.

1. Créez n’importe quel type de machine virtuelle Linux, telle qu’Ubuntu, CentOS ou autre. Renseignez les champs requis, puis sélectionnez Suivant : Disques.

   

2. Créez un disque non managé pour votre machine virtuelle. Utilisez les valeurs par défaut ou spécifiez n’importe quelle valeur pour les champs comme taille de disque du système d’exploitation, type de disque du système d’exploitationet type de chiffrement.

   

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

   capture d’écran V M.

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

   1. Sélectionnez Attacher des disques existants:

      

      

   2. Recherchez votre compte de stockage VHD.

   3. Sélectionnez conteneur, puis sélectionnez votre disque dur virtuel.

   4. Sélectionnez OK.

      

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

5. Redémarrez la machine virtuelle.

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

   

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

   1. Entrez fdisk /dev/sdb commande.

   2. Pour afficher la liste de partitions existante à partir 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 requise.

      

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

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

      Important

      Toutes les données existantes seront effacées jusqu’en 2048 secteurs (chaque secteur de 512 octets). Sauvegardez le disque dur virtuel avant de créer une partition.

      

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

      

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

      

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

N’envoyez jamais d’informations d’identification par défaut avec le disque dur virtuel envoyé. L’ajout d’informations d’identification par défaut rend le disque dur virtuel plus vulnérable aux menaces de sécurité. Au lieu de cela, créez vos propres informations d’identification lorsque vous envoyez le disque dur virtuel.

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 est traité comme un problème de mappage.

Soumettez à nouveau la requête avec le séquencement approprié des disques de données.

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

Si toutes les images extraites 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 le redéploie en tant que machine virtuelle distincte.

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

• Pour Windows, vous généralisez les images Windows à l’aide de sysreptool.

  Pour plus d’informations sur l’outil sysreptool, consultez vue d’ensemble de la préparation du système (Sysprep).

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

Erreur	Raison	Solution
DataDisk- InvalidUrl:	Cette erreur peut se produire en raison d’un numéro d’unité logique (LUN) non valide lorsque l’offre est envoyée.	Vérifiez que la séquence de numéros d’unité logique pour le disque de données se trouve dans l’Espace partenaires.
DataDisk- NotFound:	Cette erreur peut se produire, car un disque de données n’est pas situé à l’URL SAP spécifiée.	Vérifiez que le disque de données se trouve à l’URL SAP spécifiée.

Cette erreur s’affiche 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 soumettre.

Cette erreur s’affiche si la taille de l’historique Bash dans votre image soumise est supérieure à 1 kilo-octet (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 Exécuter la commande sur le portail Azure.

   

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

   

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

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

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

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 à l’appliance virtuelle réseau est de vérifier comment l’image NVA orchestre avec la pile SDN.

Cas de test	Étapes d’exécution du cas de test	Solution
Accès au disque dur virtuel	Vérifiez que l’URL SAS correcte pour le disque dur virtuel est fournie, les autorisations sont définies pour autoriser l’accès et l’image NVA est généralisée.	Vérifiez l’image NVA et l’URL fournie.
Déploiement de l’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 terminé en 20 minutes.	Si le déploiement n’est pas terminé dans les 20 minutes, vérifiez l’image NVA.
Redémarrage de l’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 le 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 pu apparaître 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 de l’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 pu apparaître 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 l’adresse IP publique est attachée, la référence SKU doit être standard et la méthode d’allocation 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 référence SKU Standard - Adresse IP frontale utilisant la méthode d’allocation d’adresses IP privées comme dynamique - Sondes d’intégrité utilisant TCP, port 22 avec un intervalle de nouvelle tentative de 15 secondes - Une règle d’équilibrage de charge avec le protocole comme toutes les et activer l’adresse IP flottante définie sur False. - Pool principal pointant vers une machine virtuelle NVA. Une fois la configuration prête, vérifiez que la machine virtuelle NVA est accessible dans l’équilibreur de charge à l’aide de la commande Netcat.	Si l’appliance virtuelle réseau n’est pas accessible dans l’équilibreur de charge, vérifiez la configuration de la machine virtuelle, de l’équilibreur de charge et de la fonctionnalité de ports haute disponibilité. Si tout est précis, il peut y avoir un problème avec l’image de l’appliance virtuelle réseau.
Peering de réseaux virtuels	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éer de peering de réseaux virtuels entre VNET1 et VNET2 et Trafic vers un réseau virtuel distant est configuré en tant que Autoriser (par défaut) Une fois la configuration prête, vérifiez qu’à partir de VM2, nous pouvons atteindre l’adresse IP privée de la carte réseau sur la machine virtuelle NVA1, à l’aide de la commande Netcat.	Si la machine virtuelle NVA1 est inaccessible à partir de VM2, vérifiez que le peering de réseaux virtuels est configuré correctement et 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 (AN)	Déployez une machine virtuelle avec l’appliance virtuelle réseau et 1 une carte réseau activée pour an. Vous pouvez activer AN 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 la 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.
Base de plusieurs cartes réseau	Déployez une machine virtuelle à l’aide de l’appliance virtuelle réseau avec 3 cartes réseau avec une méthode d’allocation IP dynamique et une référence SKU de base. Obtenez une adresse IP privée et MAC pour toutes les cartes réseau (reportez-vous à afficher l’interface réseau pour obtenir des instructions). Ensuite, redéployez la machine virtuelle et vérifiez que l’adresse IP privée et MAC de toutes les cartes réseau reste la même 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 du 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 NVA. Vérifiez ensuite 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’il 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>, où

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

Par exemple, nc 192.168.1.1 22

Les serveurs de publication peuvent demander des exceptions pour quelques tests effectués lors de la certification de machine virtuelle. Les exceptions sont fournies dans de rares cas lorsqu’un éditeur fournit des preuves pour prendre en charge 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 comment en demander une.

Scénarios d’exception

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

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

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

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

Informations à fournir pour les scénarios d’exception

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

• ID du serveur de publication. Tapez votre ID de serveur de publication du portail Partner Central.

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

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

• version. Entrez la version de l’offre de machine virtuelle qui nécessite 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 votre 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 ARM personnalisé en tant que pièce jointe.

  Si vous ne parvenez pas à inclure ces pièces jointes, votre demande est refusée.

Cette section explique comment fournir une nouvelle image de machine virtuelle lorsqu’une vulnérabilité ou une attaque est découverte avec l’une de vos images de machine virtuelle. Elle s’applique uniquement aux offres de machines virtuelles Azure publiées sur la Place de marché Azure.

Note

Vous ne pouvez pas supprimer la dernière image de machine virtuelle d’un plan ou arrêter de vendre le dernier plan pour une offre.

Effectuez l’une des actions suivantes :

• Si vous avez une nouvelle image de machine virtuelle pour remplacer l’image de machine virtuelle vulnérable, consultez Fournir une image de machine virtuelle fixe.
• Si vous n’avez pas d’image de machine virtuelle pour remplacer la seule image de machine virtuelle dans un plan, ou si vous avez terminé avec le plan, arrêter la distribution du plan.
• Si vous n’envisagez pas de remplacer la seule image de machine virtuelle dans l’offre, nous vous recommandons de cesser de distribuer l’offre.

Fournir une image de machine virtuelle fixe

Pour fournir une image de machine virtuelle fixe pour remplacer une image de machine virtuelle présentant une vulnérabilité ou une exploitation :

1. Fournissez une nouvelle image de machine virtuelle pour résoudre la vulnérabilité de sécurité ou l’exploitation.
2. Supprimez l’image de machine virtuelle avec la vulnérabilité de sécurité ou exploitez-la.
3. Republiez l’offre.

Fournir une nouvelle image de machine virtuelle pour résoudre la vulnérabilité de sécurité ou exploiter

Pour effectuer ces étapes, préparez les ressources techniques de l’image de machine virtuelle que vous souhaitez ajouter. Pour plus d’informations, consultez Créer une machine virtuelle à l’aide d’un de base approuvé ou Créer une machine virtuelle à l’aide de votre propre d’images et Générer un URI SAP pour votre image de machine virtuelle.

1. Connectez-vous à de l’Espace partenaires.

2. Dans la page d’accueil, sélectionnez la vignette 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.

   Note

   Vous ne pouvez ajouter qu’une seule image de machine virtuelle à un seul plan à 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, fournissez une nouvelle version de disque et l’image de machine virtuelle.

7. Sélectionnez Enregistrer le brouillon.

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

Supprimer l’image de machine virtuelle avec la vulnérabilité de sécurité ou exploiter

1. Connectez-vous à de l’Espace partenaires.
2. Dans la page d’accueil, sélectionnez la vignette 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, en regard de l’image de machine virtuelle à supprimer, sélectionnez Supprimer l’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 devez fournir des informations à l’équipe de certification, ajoutez-la à la zone Notes de certification pour la certification box.
3. Sélectionnez publier.

Pour terminer le processus de publication, consultez Vérifier et publier des offres.

Cette section explique comment fournir une nouvelle image de machine virtuelle lorsqu’une vulnérabilité liée à TLS est découverte avec l’une de vos images de machine virtuelle. Elle s’applique uniquement aux offres de machines virtuelles Azure publiées sur la Place de marché Azure.

Étapes de correction

Pour résoudre ces vulnérabilités, procédez comme suit :

Désactivez l’utilisation des protocoles TLS 1.0 et 1.1 et vérifiez que l’image de machine virtuelle prend en charge TLS version 1.2 ou ultérieure. Pour ce faire, définissez les clés de Registre ou les paramètres de configuration appropriés dans l’image de machine virtuelle.

Pour Linux, utilisez les commandes suivantes pour tester manuellement et vérifier que ces versions sont désactivées :

• pour TLS 1.0 :

  openssl s_client -connect ip:port -tls1
  

• pour TLS 1.1 :

  openssl s_client -connect ip:port -tls1_1
  

Pour Windows, reportez-vous à la documentation officielle paramètres du Registre TLS pour mettre à jour les clés de Registre. Utilisez les commandes PowerShell suivantes pour configurer les paramètres TLS :

Chemin	Nom	Valeur
HKLM :\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client	« Activé »	0
HKLM :\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server	« Activé »	0
HKLM :\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client	« Activé »	0
HKLM :\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server	« Activé »	0
HKLM :\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client	« Activé »	1
HKLM :\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server	« Activé »	1

Activation de versions ultérieures (facultatif)

Si vous souhaitez activer des versions ultérieures (par exemple, TLS 1.3), répétez les étapes ci-dessus avec les chemins et valeurs correspondants pour ces versions.

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

Offre désactivée SSH (ou) verrouillée

Les images publiées avec SSH désactivées (pour Linux) ou RDP désactivées (pour Windows) sont traitées comme des machines virtuelles verrouillées. Il existe des scénarios métier spéciaux en raison desquels les serveurs de publication autorisent uniquement l’accès restreint à aucun/a quelques utilisateurs.

Pendant les vérifications de validation, les machines virtuelles verrouillées peuvent 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 où publisher peut nécessiter 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 qui sont requises pour l’exécution du modèle ARM.

Extensions de machine virtuelle

Les extensions de machine virtuelle Azure sont de petites applications qui fournissent des tâches de configuration post-déploiement et d’automatisation sur des machines virtuelles Azure. Par exemple, si une machine virtuelle nécessite une installation logicielle, une protection antivirus ou pour exécuter un script à l’intérieur de celui-ci, une extension de machine virtuelle peut être utilisée.

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

• L’agent Linux Azure version minimale prise en charge ou une version ultérieure doit être installé.](https://learn.microsoft.com/troubleshoot/azure/virtual-machines/support-extensions-agent-version)
• Version python supérieure à 2.6+

Pour plus d’informations, visitez d’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 1 Mo d’abord est réservé 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.

Contenu connexe

• Configurer les propriétés de l’offre de machine virtuelle
• récompenses Place de marché active
• Si vous avez des questions ou des commentaires sur l’amélioration, contactez support de l’Espace partenaires