Una máquina virtual Linux de Azure en un kernel basado en 3.10 entra en pánico después de una actualización del nodo host
Nota:
CentOS al que se hace referencia en este artículo es una distribución de Linux y llegará al final de la vida útil (EOL). Considere su uso y planifique en consecuencia. Para obtener más información, consulte Guía de fin de vida de CentOS.
En este artículo se describe un problema que se produce cuando una máquina virtual Linux de Azure que ejecuta el kernel basado en 3.10 se bloquea después de una actualización del nodo de host en Azure.
Versión original del producto: Máquina virtual que ejecuta Linux, máquina virtual que ejecuta RedHat
Número de KB original: 3212236
Síntomas
Imagine la siguiente situación:
Tiene una máquina virtual (VM) Microsoft Azure Linux que ejecuta una distribución basada en RHEL/CentOS con una versión del kernel de Linux anterior a la versión 3.10.0-327.10.1, incluidas las que se incluyen con:
- Red Hat Enterprise Linux 7.1 y 7.0
- CentOS 7.1 y 7.0
- Oracle Linux 7.1 y 7.0 con kernel compatible con Red Hat
Una operación de actualización de conservación de memoria se produce en un nodo host de Azure.
En este escenario, la máquina virtual deja de responder y se registra un pánico de máquina virtual similar al siguiente en el registro serie de 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
Causa
Este problema puede deberse a una lógica de bloqueo errónea en el subsistema SCSI que se expone cuando se quita un disco SCSI de un invitado de máquina virtual basado en RHEL/CentOS en ejecución en un host Microsoft Hyper-V.
Solución
Para solucionar este problema y restaurar la funcionalidad, reinicie manualmente la máquina virtual.
Para evitar este problema en el futuro, actualice a la versión del kernel 3.10.0-327.10.1 o una versión posterior, incluidas las que se encuentran en:
- Red Hat Enterprise Linux 7.2
- CentOS 7.2
- Oracle Linux 7.2 con kernel compatible con Red Hat
Más información
Para obtener más información sobre las distribuciones de Linux aprobadas y las tecnologías de código abierto en Azure, consulte Compatibilidad con linux y tecnología de código abierto en Azure.
Ponte en contacto con nosotros para obtener ayuda
Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.
Aviso de declinación de responsabilidades sobre la información de terceros
Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.
Comentarios
https://aka.ms/ContentUserFeedback.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea:Enviar y ver comentarios de