VMWare for Linux + Win10 导致 Ext4 模块崩溃 bug
1. 系统环境
宿主机操作系统:Fedora 29
VMware 版本:VMware® Workstation 15 Pro build-10952284
虚拟机系统:Windows 10 Home 版
2. 故障现象
在保存 Windows 10 快照或关闭 Windows 时,经常遇到 VMware 彻底卡死的状态,对应的进程状态为 D(Uninterruptible sleep),uninterruptible sleep 状态一般是在等待外部设备的 I/O,D 状态进程是不会接收系统的信号的,所以无法 kill 掉,这种情况只能强制重启系统了。
用 journalctl 查看日志,发现下面这段:
1月 07 12:43:14 pc kernel: WARNING: CPU: 6 PID: 5006 at fs/ext4/inode.c:3897 ext4_set_page_dirty+0x48/0x50 1月 07 12:43:14 pc kernel: Modules linked in: snd_seq_dummy dm_crypt loop binfmt_misc xt_CHECKSUM ipt_MASQUERADE tun nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 bridge xt_conntrack stp llc ebtable_nat ip6table_nat nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat_ipv4 nf_nat iptable_mangle iptable_raw iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables vmnet(OE) ppdev parport_pc parport fuse vmw_vsock_vmci_transport vsock vmw_vmci vmmon(OE) bnep sunrpc arc4 iwlmvm intel_rapl x86_pkg_temp_thermal intel_powerclamp iTCO_wdt iTCO_vendor_support coretemp mac80211 kvm_intel snd_soc_skl snd_soc_skl_ipc crct10dif_pclmul crc32_pclmul snd_soc_sst_ipc snd_hda_codec_hdmi 1月 07 12:43:14 pc kernel: snd_soc_sst_dsp ghash_clmulni_intel intel_cstate snd_hda_ext_core snd_soc_acpi_intel_match iwlwifi snd_soc_acpi intel_uncore snd_soc_core snd_hda_codec_realtek intel_rapl_perf uvcvideo snd_hda_codec_generic snd_compress btusb ac97_bus videobuf2_vmalloc snd_pcm_dmaengine btrtl cfg80211 videobuf2_memops btbcm videobuf2_v4l2 btintel snd_hda_intel videobuf2_common bluetooth snd_hda_codec joydev snd_hda_core videodev wmi_bmof snd_hwdep snd_seq intel_wmi_thunderbolt snd_seq_device media snd_pcm i2c_i801 ecdh_generic idma64 mei_me mei snd_timer thinkpad_acpi intel_lpss_pci intel_pch_thermal intel_lpss snd soundcore rfkill int3403_thermal ucsi_acpi processor_thermal_device int340x_thermal_zone typec_ucsi int3400_thermal acpi_thermal_rel intel_soc_dts_iosf typec acpi_pad pcc_cpufreq hid_logitech_hidpp 1月 07 12:43:14 pc kernel: hid_logitech_dj i915 kvmgt mdev vfio kvm irqbypass i2c_algo_bit drm_kms_helper drm e1000e crc32c_intel uas serio_raw wmi usb_storage video 1月 07 12:43:14 pc kernel: CPU: 6 PID: 5006 Comm: vmx-vcpu-0 Tainted: G W OE 4.19.13-300.fc29.x86_64 #1 1月 07 12:43:14 pc kernel: Hardware name: LENOVO 20L5A028HK/20L5A028HK, BIOS N24ET35W (1.10 ) 02/12/2018 1月 07 12:43:14 pc kernel: RIP: 0010:ext4_set_page_dirty+0x48/0x50 1月 07 12:43:14 pc kernel: Code: 08 48 8d 42 ff 83 e2 01 48 0f 44 c7 48 8b 00 a8 10 74 0d 48 8b 07 f6 c4 10 74 0f e9 82 81 f8 ff 0f 0b 48 8b 07 f6 c4 10 75 f1 <0f> 0b eb ed 0f 1f 40 00 0f 1f 44 00 00 41 54 41 89 d4 55 48 89 fd 1月 07 12:43:14 pc kernel: RSP: 0018:ffff9c900bf97d58 EFLAGS: 00010246 1月 07 12:43:14 pc kernel: RAX: 0017fffe00010028 RBX: ffff9156cd538068 RCX: 0000000000000000 1月 07 12:43:14 pc kernel: RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffbe0eccae8fc0 1月 07 12:43:14 pc kernel: RBP: 0000000000000001 R08: 0000000000000000 R09: ffff9155bb66e6a8 1月 07 12:43:14 pc kernel: R10: 0000000000000228 R11: 0000000000000000 R12: 0000000000000001 1月 07 12:43:14 pc kernel: R13: 0000000000000041 R14: ffff9156cd538060 R15: 0000000000000002 1月 07 12:43:14 pc kernel: FS: 00007f416ea0e700(0000) GS:ffff9156ef780000(0000) knlGS:0000000000000000 1月 07 12:43:14 pc kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 1月 07 12:43:14 pc kernel: CR2: 00007f407f69f000 CR3: 0000000399026004 CR4: 00000000003606e0 1月 07 12:43:14 pc kernel: Call Trace: 1月 07 12:43:14 pc kernel: qp_release_pages+0x68/0xc0 [vmw_vmci] 1月 07 12:43:14 pc kernel: qp_host_unregister_user_memory.isra.22+0x22/0x70 [vmw_vmci] 1月 07 12:43:14 pc kernel: vmci_qp_broker_detach+0x261/0x390 [vmw_vmci] 1月 07 12:43:14 pc kernel: vmci_host_unlocked_ioctl+0x194/0xa40 [vmw_vmci] 1月 07 12:43:14 pc kernel: ? selinux_file_ioctl+0x161/0x200 1月 07 12:43:14 pc kernel: do_vfs_ioctl+0xa4/0x630 1月 07 12:43:14 pc kernel: ksys_ioctl+0x60/0x90 1月 07 12:43:14 pc kernel: __x64_sys_ioctl+0x16/0x20 1月 07 12:43:14 pc kernel: do_syscall_64+0x5b/0x160 1月 07 12:43:14 pc kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 1月 07 12:43:14 pc kernel: RIP: 0033:0x7f417d7bc09b 1月 07 12:43:14 pc kernel: Code: 0f 1e fa 48 8b 05 ed bd 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d bd bd 0c 00 f7 d8 64 89 01 48 1月 07 12:43:14 pc kernel: RSP: 002b:00007f416ea05af8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 1月 07 12:43:14 pc kernel: RAX: ffffffffffffffda RBX: 00007f416ea05b10 RCX: 00007f417d7bc09b 1月 07 12:43:14 pc kernel: RDX: 00007f416ea05b10 RSI: 00000000000007aa RDI: 0000000000000062 1月 07 12:43:14 pc kernel: RBP: 000055a34c3896e0 R08: 0000000000000000 R09: 00007f416ea05c50 1月 07 12:43:14 pc kernel: R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000020 1月 07 12:43:14 pc kernel: R13: 00000000fffffffe R14: 0000000000000020 R15: 00007f416ea8d000 1月 07 12:43:14 pc kernel: ---[ end trace ef73c1bbbca160ca ]---
从日志显示的上下文调用栈来看,崩溃是由 vmci 驱动造成的。VMCI 用于宿主机和虚拟机之间的通信,可以提高通讯性能。
通过 Google 了一把,我摸索出的解决方案有两个:
1、禁用 VMCI,编辑 Win10 虚拟机的 .vmx 文件,把 vmci0.present = "TRUE"
改成 vmci0.present = "FALSE"
2、存放虚拟机文件的分区格式化成 XFS 文件系统(反正不用 Ext4)
在 VMware 的社区也找到相应的讨论:https://communities.vmware.com/thread/570719
两种方法我都测试了,因为我虚拟机文件都单独存在一个分区中的,为了一劳永逸,最终还是选了第二个方法,把文件系统格式化成 XFS 的了。
3. 更多参考
- VMWare 官方的 KB 库:https://kb.vmware.com/s/article/2142110?lang=zh_CN
- VMware 社区中相应的讨论:https://communities.vmware.com/thread/570719
- Ubuntu 社区的反馈:https://www.mail-archive.com/[email protected]/msg308354.html
- Gentoo 社区的反馈:https://archives.gentoo.org/gentoo-user/message/f1293f2f8a567c58531592eafa1cc569