Une machine virtuelle Linux Azure sur un noyau 3.10 panique après une mise à niveau d’un nœud hôte

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.