Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für: ✔️ Linux-VMs
Ursprüngliche KB-Nummer: 3212236
Notiz
CentOS, auf das in diesem Artikel verwiesen wird, ist eine Linux-Verteilung und wird End Of Life (EOL) erreichen. Erwägen Sie Ihre Verwendung und planen Sie entsprechend. Weitere Informationen finden Sie unter CentOS End Of Life Guidance.
Zusammenfassung
In diesem Artikel wird ein Problem erläutert, das auftritt, wenn ein Azure Linux-VM, auf dem der 3.10-basierte Kernel ausgeführt wird, nach einem Hostknotenupgrade in Azure abstürzt.
Symptome
Stellen Sie sich folgendes Szenario vor:
Sie verfügen über eine Microsoft Azure Linux-VM (virtuelle Maschine), die eine RHEL/CentOS-basierte Distribution mit einer Linux-Kernelversion vor Version 3.10.0-327.10.1 ausführt, einschließlich derer, die enthalten sind:
- Red Hat Enterprise Linux 7.1 und 7.0
- CentOS 7.1 und 7.0
- Oracle Linux 7.1 und 7.0 mit Red Hat-kompatiblem Kernel
Ein Updatevorgang mit Speichererhaltung tritt auf einem Azure-Hostknoten auf.
In diesem Szenario reagiert der virtuelle Computer nicht mehr, und eine VM-Panik, die wie folgt aussieht, wird im seriellen Linux-Protokoll protokolliert:
[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
Ursache
Dieses Problem kann durch fehlerhafte Sperrlogik im SCSI-Subsystem verursacht werden, das verfügbar gemacht wird, wenn ein SCSI-Datenträger von einem ausgeführten RHEL/CentOS-basierten VM-Gast auf einem Microsoft Hyper-V-Host entfernt wird.
Lösung
Um dieses Problem zu beheben und die Funktionalität wiederherzustellen, starten Sie den virtuellen Computer manuell neu.
Um dieses Problem in Zukunft zu vermeiden, aktualisieren Sie auf Kernelversion 3.10.0-327.10.1 oder eine höhere Version, einschließlich der in:
- Red Hat Enterprise Linux 7.2
- CentOS 7.2
- Oracle Linux 7.2 mit Red Hat-kompatiblem Kernel
Weitere Informationen:
Weitere Informationen zu Endorsed Linux-Distributionen und Open-Source-Technologien in Azure finden Sie unter dem Titel "Support for Linux and Open Source technology in Azure".
Informationen zum Haftungsausschluss von Drittanbietern
Die in diesem Artikel erläuterten Drittanbieterprodukte werden von Unternehmen hergestellt, die unabhängig von Microsoft sind. Microsoft übernimmt keine Garantie, impliziert oder anderweitig, über die Leistung oder Zuverlässigkeit dieser Produkte.