Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : ✔️ Machines virtuelles Linux
Numéro de base de connaissances d’origine : 3212236
Note
CentOS référencé dans cet article est une distribution Linux et atteindra sa fin de vie (EOL). Faites le point sur votre utilisation et organisez-vous en conséquence. Pour plus d'informations, consultez les recommandations CentOS End Of Life.
Résumé
Cet article décrit un problème qui se produit lorsqu'une machine virtuelle Linux Azure qui exécute le noyau 3.10 se bloque après une mise à niveau d'un nœud hôte dans Azure.
Symptômes
Examinez le cas suivant :
Vous disposez d’une machine virtuelle Linux Microsoft Azure qui exécute une distribution basée sur RHEL/CentOS avec une version de noyau Linux antérieure à la version 3.10.0-327.10.1, y compris celles qui sont incluses dans :
- Red Hat Enterprise Linux 7.1 et 7.0
- CentOS 7.1 et 7.0
- Oracle Linux 7.1 et 7.0 avec noyau compatible Red Hat
Une opération de mise à jour préservant la mémoire se produit sur un nœud hôte Azure.
Dans ce scénario, la machine virtuelle ne répond plus et une panique de machine virtuelle semblable à celle-ci est consignée dans le journal série Linux :
[11480839.438577] Call Trace:
[11480839.439615] [<ffffffff816045b6>] dump_stack+0x19/0x1b
[11480839.441556] [<ffffffff8106e29b>] warn_slowpath_common+0x6b/0xb0
[11480839.443818] [<ffffffff8106e33c>] warn_slowpath_fmt+0x5c/0x80
[11480839.445983] [<ffffffff8123e585>] sysfs_add_one+0xa5/0xd0
[11480839.447983] [<ffffffff8123e77c>] create_dir+0x7c/0xe0
[11480839.449876] [<ffffffff8123eb29>] sysfs_create_dir+0xa9/0x130
[11480839.451971] [<ffffffff812d74ab>] kobject_add_internal+0xbb/0x2f0
[11480839.454310] [<ffffffff812d79e5>] kobject_add+0x75/0xd0
[11480839.456236] [<ffffffff813cfa85>] device_add+0x125/0x7a0
[11480839.458167] [<ffffffff813df9fc>] ? __pm_runtime_resume+0x5c/0x80
[11480839.460469] [<ffffffff813fe9cc>] scsi_sysfs_add_sdev+0xac/0x280
[11480839.462628] [<ffffffff813fcfbb>] do_scan_async+0x7b/0x150
[11480839.464632] [<ffffffff8109e849>] async_run_entry_fn+0x39/0x120
[11480839.467170] [<ffffffff8108f0cb>] process_one_work+0x17b/0x470
[11480839.469354] [<ffffffff8108fe9b>] worker_thread+0x11b/0x400
[11480839.472310] [<ffffffff8108fd80>] ? rescuer_thread+0x400/0x400
[11480839.475265] [<ffffffff8109727f>] kthread+0xcf/0xe0
[11480839.477904] [<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
[11480839.481074] [<ffffffff81614358>] ret_from_fork+0x58/0x90
[11480839.483873] [<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
[11480839.487072] ---[ end trace 1f7736c59e96a8a0 ]---
[11480839.489584] ------------[ cut here ]------------
......
[11480864.118093] Call Trace:
[11480864.118093] [<ffffffff815f2535>] klist_put+0x25/0xa0
[11480864.118093] [<ffffffff815f25be>] klist_del+0xe/0x10
[11480864.118093] [<ffffffff813ce908>] device_del+0x58/0x1f0
[11480864.118093] [<ffffffff813ceabe>] device_unregister+0x1e/0x60
[11480864.118093] [<ffffffff812c36ee>] bsg_unregister_queue+0x5e/0xa0
[11480864.118093] [<ffffffff813fec49>] __scsi_remove_device+0xa9/0xd0
[11480864.118093] [<ffffffff813fcfc7>] do_scan_async+0x87/0x150
[11480864.118093] [<ffffffff8109e849>] async_run_entry_fn+0x39/0x120
[11480864.118093] [<ffffffff8108f0cb>] process_one_work+0x17b/0x470
[11480864.118093] [<ffffffff8108fe9b>] worker_thread+0x11b/0x400
[11480864.118093] [<ffffffff8108fd80>] ? rescuer_thread+0x400/0x400
[11480864.118093] [<ffffffff8109727f>] kthread+0xcf/0xe0
[11480864.118093] [<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
[11480864.118093] [<ffffffff81614358>] ret_from_fork+0x58/0x90
[11480864.118093] [<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
Cause
Ce problème peut être dû à une logique de verrouillage défectueux dans le sous-système SCSI exposé lorsqu’un disque SCSI est supprimé d’un invité de machine virtuelle RHEL/CentOS en cours d’exécution sur un hôte Microsoft Hyper-V.
Résolution
Pour résoudre ce problème et la fonctionnalité de restauration, redémarrez manuellement la machine virtuelle.
Pour éviter ce problème à l’avenir, mettez à jour vers le noyau version 3.10.0-327.10.1 ou une version ultérieure, y compris celles qui se trouvent dans :
- Red Hat Enterprise Linux 7.2
- CentOS 7.2
- Oracle Linux 7.2 avec noyau compatible Red Hat
Informations supplémentaires
Pour plus d’informations sur les distributions Linux Endorsed Linux et open source dans Azure, consultez Support pour linux et technologie de open source dans Azure.
Exclusion de responsabilité de tiers
Les produits tiers que cet article traite sont fabriqués par des entreprises indépendantes de Microsoft. Microsoft n’apporte aucune garantie, implicite ou autre, sur les performances ou la fiabilité de ces produits.