Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Ubuntu 20.04 + vmWare WS 16.1.1 + LUKS volume -> crashes

Hilfe bei Problemen mit der Installation und Benutzung der VMware Workstation und VMware Workstation Pro.

Moderatoren: irix, Dayworker

Member
Beiträge: 4
Registriert: 06.05.2021, 16:57

Ubuntu 20.04 + vmWare WS 16.1.1 + LUKS volume -> crashes

Beitragvon JoeMs2021 » 06.05.2021, 19:27

Hi zusammen,

leider habe ich seit geraumer Zeit Probleme mit Instabilitäten bei vmWare. Wann es genau losgegangen ist, kann ich nicht mehr sagen, aber möglicherweie nach dem Wechsel von Ubuntu 18.04 LTS auf 20.04 LTS.
Es geht um diese Kombination:

  • Lenovo P50 Notebook mit Intel Xeon E3-1535M, 64GB ECC-RAM
  • eine Samsung SSD 970 PRO 1TB für das Betriebssystem
  • eine Samsung SSD 960 PRO 2TB für die virtuellen Maschinen und weitere Daten (eine einzige große Partition, mit LUKS verschlüsselt)
  • Ubuntu 20.04 LTS
  • vmWare Workstation 16.1.1

Immer häufiger hängt sich vmWare Workstation komplett auf, wenn ein Gast-Betriebssystem herunterfährt oder eigentlich mit dem Herunterfahren fertig ist. Die meisten Gastsysteme sind Windows, u.a. Windows 2008 R2 Server und Windows 2012 R2 Server. Mein Eindruck ist, dass die Probleme eher eintreten, je größer die Speicherauslastung ist bzw. je mehr virtuelle Maschinen aktiv laufen.
Das Aufhängen äußert sich so, dass der dagestellte virtuelle PC dauerhaft in der Phase des Herunterfahrens festhängt. Es ist dann auch nicht mehr möglich, zu anderen VMs umzuschalten oder die betroffene Maschine via virtuellem "power off" zu killen, vmWare Workstation ist praktisch unbenutzbar. Man kann das Fenster nicht schließen. htop zeigt, dass die VM, die beim Herunterfahren hängengeblieben ist, weiterhin relativ viel CPU-Last erzeugt. Der Prozess kann mit kill -9 nicht beendet werden, er bleibt einfach weiter da und verheizt CPU-Zeit. Die übrigen VMs scheinen nach diesem Geschehen ebenfalls nicht mehr erreichbar zu sein, auch nicht via RDP. Wenn ich vmWare Workstation ein weiteres mal als neues Fenster öffne, zeigt mir dieses nur ladende Tabs für alle laufenden VMs, diese werden aber nie belebt, sondern bleiben im Ladezustand hängen.
Übrige Prozesse laufen stabil weiter, auch alle Dateien auf dem verschlüsselten Volume sind weiterhin nutzbar, nur vmWare kann erst nach einem kompletten Reboot wieder genutzt werden, alle virtuellen Gastsysteme werden dabei natürlich "hart" ausgeschaltet. Beim Herunterfahren des Ubuntu-System bleibt es dann ebenfalls hängen und der Computer muss via Power Cycle neugestartet werden.

Im dmesg-Log finde ich von genau der Zeit, wenn dies passiert, folgende Info:

Code: Alles auswählen

Thu May  6 16:39:56 2021 ------------[ cut here ]------------
Thu May  6 16:39:56 2021 WARNING: CPU: 4 PID: 8950 at fs/ext4/inode.c:3918 ext4_set_page_dirty+0x44/0x60
Thu May  6 16:39:56 2021 Modules linked in: dm_crypt thunderbolt isofs rfcomm acpi_call(OE) xt_CHECKSUM ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle nf_tables ip6table_filter ip6_tables vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_filter iptable_nat md4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bpfilter br_netfilter bridge stp llc vmnet(OE) vmw_vsock_vmci_transport vsock vmw_vmci nls_utf8 xfrm_user xfrm_algo cifs vmmon(OE) fscache libdes cmac algif_hash algif_skcipher af_alg ccm aufs ch341 usbserial overlay bnep binfmt_misc nls_iso8859_1 btusb btrtl btbcm btintel bluetooth uvcvideo ecdh_generic ecc snd_hda_codec_hdmi joydev intel_rapl_msr mei_hdcp snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep thinkpad_acpi snd_pcm nvram ledtrig_audio snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq intel_rapl_common
Thu May  6 16:39:56 2021  snd_seq_device snd_timer x86_pkg_temp_thermal intel_powerclamp coretemp rmi_smbus rmi_core kvm_intel iwlmvm kvm mac80211 videobuf2_vmalloc rapl libarc4 snd videobuf2_memops intel_cstate videobuf2_v4l2 input_leds videobuf2_common iwlwifi videodev serio_raw rtsx_pci_ms mc intel_wmi_thunderbolt cfg80211 memstick mei_me wmi_bmof intel_pch_thermal mei ie31200_edac soundcore mac_hid nvidia_uvm(OE) sch_fq_codel parport_pc ppdev lp parport sunrpc ip_tables x_tables autofs4 hid_cherry hid_generic uas usbhid usb_storage hid nvidia_drm(POE) crct10dif_pclmul crc32_pclmul nvidia_modeset(POE) ghash_clmulni_intel rtsx_pci_sdmmc i915 nvidia(POE) nvme aesni_intel i2c_algo_bit crypto_simd drm_kms_helper cryptd i2c_i801 glue_helper syscopyarea sysfillrect sysimgblt nvme_core fb_sys_fops psmouse e1000e drm ahci rtsx_pci libahci wmi video
Thu May  6 16:39:56 2021 CPU: 4 PID: 8950 Comm: vmx-vcpu-0 Tainted: P           OE     5.4.0-45-generic #49-Ubuntu
Thu May  6 16:39:56 2021 Hardware name: LENOVO 20EN0009GE/20EN0009GE, BIOS N1EET86W (1.59 ) 08/28/2019
Thu May  6 16:39:56 2021 RIP: 0010:ext4_set_page_dirty+0x44/0x60
Thu May  6 16:39:56 2021 Code: 00 a8 01 75 16 48 8b 57 08 48 8d 42 ff 83 e2 01 48 0f 44 c7 48 8b 00 a8 08 74 0f 48 8b 07 f6 c4 20 74 11 e8 9e 75 f7 ff 5d c3 <0f> 0b 48 8b 07 f6 c4 20 75 ef 0f 0b e8 8b 75 f7 ff 5d c3 66 0f 1f
Thu May  6 16:39:56 2021 RSP: 0018:ffffb6e38338fd08 EFLAGS: 00010246
Thu May  6 16:39:56 2021 RAX: 0017ffffc0000054 RBX: ffff97fbb59c7460 RCX: 0000000000000000
Thu May  6 16:39:56 2021 RDX: 0000000000000000 RSI: 0000000000000041 RDI: fffff361b1583d40
Thu May  6 16:39:56 2021 RBP: ffffb6e38338fd08 R08: 0000000000000000 R09: ffffffffb0a78b00
Thu May  6 16:39:56 2021 R10: ffff97faf9b7f200 R11: 0000000000000001 R12: fffff361b1583d40
Thu May  6 16:39:56 2021 R13: 0000000000000041 R14: ffff97fbb59c7460 R15: 0000000000000001
Thu May  6 16:39:56 2021 FS:  00007fb6837fe700(0000) GS:ffff97fbdfd00000(0000) knlGS:0000000000000000
Thu May  6 16:39:56 2021 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Thu May  6 16:39:56 2021 CR2: 00007fb8817c3000 CR3: 00000010318b4004 CR4: 00000000003606e0
Thu May  6 16:39:56 2021 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Thu May  6 16:39:56 2021 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Thu May  6 16:39:56 2021 Call Trace:
Thu May  6 16:39:56 2021  set_page_dirty+0x61/0xc0
Thu May  6 16:39:56 2021  qp_release_pages+0x68/0xb0 [vmw_vmci]
Thu May  6 16:39:56 2021  qp_host_unregister_user_memory.isra.0+0x27/0x80 [vmw_vmci]
Thu May  6 16:39:56 2021  vmci_qp_broker_detach+0x2b3/0x3f0 [vmw_vmci]
Thu May  6 16:39:56 2021  vmci_host_unlocked_ioctl+0x9c/0xb20 [vmw_vmci]
Thu May  6 16:39:56 2021  ? eventfd_read+0xe9/0x240
Thu May  6 16:39:56 2021  do_vfs_ioctl+0x407/0x670
Thu May  6 16:39:56 2021  ? vfs_read+0x12e/0x160
Thu May  6 16:39:56 2021  ksys_ioctl+0x67/0x90
Thu May  6 16:39:56 2021  __x64_sys_ioctl+0x1a/0x20
Thu May  6 16:39:56 2021  do_syscall_64+0x57/0x190
Thu May  6 16:39:56 2021  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Thu May  6 16:39:56 2021 RIP: 0033:0x7fbab440350b
Thu May  6 16:39:56 2021 Code: 0f 1e fa 48 8b 05 85 39 0d 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 55 39 0d 00 f7 d8 64 89 01 48
Thu May  6 16:39:56 2021 RSP: 002b:00007fb6837f26e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
Thu May  6 16:39:56 2021 RAX: ffffffffffffffda RBX: 00007fb6837f2700 RCX: 00007fbab440350b
Thu May  6 16:39:56 2021 RDX: 00007fb6837f2700 RSI: 00000000000007aa RDI: 0000000000000076
Thu May  6 16:39:56 2021 RBP: 0000000000000000 R08: 0000000000000000 R09: 00007fb6837f2850
Thu May  6 16:39:56 2021 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000fffffffe
Thu May  6 16:39:56 2021 R13: 0000000000000020 R14: 0000000000000020 R15: 00007fbab2e872e0
Thu May  6 16:39:56 2021 ---[ end trace c735169021faa216 ]---


Die Fehlerinformation WARNING: CPU: 4 PID: 8950 at fs/ext4/inode.c:3918 ext4_set_page_dirty+0x44/0x60 ist immer gleich. Ich habe den Rest noch nicht systematisch verglichen, aber mit Ausnahme von ein paar Adressen wird das vermutlich immer sehr ähnlich aussehen. Die VMs laufen im Betrieb total stabil, da gibt es kein Problem. Interessanterweise geht es immer erst los, wenn ich eine oder mehrere herunterfahre. Der Hauptspeicher ist meist nicht mal zu 50% ausgelastet. Weder da noch bei den CPU/GPU-Temperaturen gerät das System an gefährliche Grenzen.
LUKS meldet keine Integritätsfehler auf dem Volume, wobei es schwierig ist, überhaupt brauchbare Daten zu bekommen. SMART geht wegen PCI-e nicht wirklich, und das, was man per smartctl herausbekommt, sieht alles unbedenklich aus:

Code: Alles auswählen

sudo smartctl -a /dev/nvme0n1
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-45-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 960 PRO 2TB
Serial Number:                      S3EXNWAJ400519P
Firmware Version:                   4B6QCXP7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 2.048.408.248.320 [2,04 TB]
Unallocated NVM Capacity:           0
Controller ID:                      2
Number of Namespaces:               1
Namespace 1 Size/Capacity:          2.048.408.248.320 [2,04 TB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 5471500dc1
Local Time is:                      Thu May  6 19:21:28 2021 CEST
Firmware Updates (0x16):            3 Slots, no Reset required
Optional Admin Commands (0x0007):   Security Format Frmw_DL
Optional NVM Commands (0x001f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Maximum Data Transfer Size:         512 Pages
Warning  Comp. Temp. Threshold:     73 Celsius
Critical Comp. Temp. Threshold:     76 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     6.90W       -        -    0  0  0  0        0       0
 1 +     5.50W       -        -    1  1  1  1        0       0
 2 +     5.10W       -        -    2  2  2  2        0       0
 3 -   0.0500W       -        -    3  3  3  3      210    1200
 4 -   0.0080W       -        -    4  4  4  4     2000    6000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        38 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    460.559.158 [235 TB]
Data Units Written:                 53.970.969 [27,6 TB]
Host Read Commands:                 9.832.257.903
Host Write Commands:                1.175.885.662
Controller Busy Time:               3.053
Power Cycles:                       1.613
Power On Hours:                     4.438
Unsafe Shutdowns:                   252
Media and Data Integrity Errors:    0
Error Information Log Entries:      4.634
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               38 Celsius
Temperature Sensor 2:               45 Celsius

Error Information (NVMe Log 0x01, max 64 entries)
Num   ErrCount  SQId   CmdId  Status  PELoc          LBA  NSID    VS
  0       4634     0  0x001e  0x421a  0x028            0     0     -
  1       4633     0  0x001c  0x4212  0x028            0     0     -
  2       4632     0  0x0008  0x4004      -            0     0     -
  3       4631     0  0x001c  0x421a  0x028            0     0     -
  4       4630     0  0x001a  0x4212  0x028            0     0     -
  5       4629     0  0x0008  0x4004      -            0     0     -
  6       4628     0  0x001e  0x421a  0x028            0     0     -
  7       4627     0  0x001c  0x4212  0x028            0     0     -
  8       4626     0  0x0008  0x4004      -            0     0     -
  9       4625     0  0x001c  0x421a  0x028            0     0     -
 10       4624     0  0x001a  0x4212  0x028            0     0     -
 11       4623     0  0x0008  0x4004      -            0     0     -
 12       4622     0  0x001c  0x421a  0x028            0     0     -
 13       4621     0  0x001a  0x4212  0x028            0     0     -
 14       4620     0  0x0008  0x4004      -            0     0     -
 15       4619     0  0x001c  0x421a  0x028            0     0     -
... (48 entries not shown)


Die 4.634 Error Log Entries sind nicht toll, aber es scheint sich dabei eher nicht um harte Fehler zu handeln.
Ich weiß nun nicht mehr so richtig weiter. Dass es ein Bug im ext4-Dateisystem sein soll, kann ich nicht wirklich glauben. Dann eher LUKS, aber eine Volume-Verschlüsselung muss sein, weil die virtuellen Maschinen jeweils Kundendaten enthalten und im Fall, dass das Notebook abhanden kommt, auf keinen Fall in die falschen Hände geraten dürfen.
Ich hoffe, irgendjemand hat eine Idee, wie man das Problem genauer eingrenzen kann. Ich liefere gerne weitere Daten, weiß aber nicht genau, was jetzt am ehesten weiterhilft, und würde mich deshalb um entsprechende Nachfragen / Anweisungen freuen.
Danke sehr und herzliche Grüße in die Runde!

Guru
Beiträge: 2731
Registriert: 23.02.2012, 12:26

Re: Ubuntu 20.04 + vmWare WS 16.1.1 + LUKS volume -> crashes

Beitragvon ~thc » 06.05.2021, 20:18

Ich bin mir ziemlich sicher, dass du mit deiner hochspezifischen Kombination aus Hard- und Software einen Mainline-Kernel-Bug triggerst. Das Problem bei Ubuntu ist, dass ein Alternativ-Kernel nicht so leicht verfügbar ist. Eine einfache Lösung fällt mir daher nicht ein.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Ubuntu 20.04 + vmWare WS 16.1.1 + LUKS volume -> crashes

Beitragvon Dayworker » 06.05.2021, 22:48

Ich denke auch, daß ein Bug getriggert wird: "fs/ext4/inode.c:3918 ext4_set_page_dirty+0x44/0x60" liefert diverse Einträge.

Member
Beiträge: 4
Registriert: 06.05.2021, 16:57

Re: Ubuntu 20.04 + vmWare WS 16.1.1 + LUKS volume -> crashes

Beitragvon JoeMs2021 » 07.05.2021, 11:10

Servus,

ich danke Euch für die Antworten. Kann man denn gar nichts tun? Wenn das ein Bug ist, sollte er doch früher oder später mal behoben werden, oder? Kann ich irgendeinen Weg finden, den Fehler zu umgehen?
Leider bin ich in der Linux-Welt nicht besonders erfahren, vor ca. 1,5 Jahren von Windows gewechselt, würde aber gerne bei diesem Wechsel bleiben, denn was M$ da verkauft, ist einfach nur noch dreist. Man muss aber zugestehen, dass es solche Probleme mit vmWare dort nicht gab.

Viele Grüße
Joe

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: Ubuntu 20.04 + vmWare WS 16.1.1 + LUKS volume -> crashes

Beitragvon Dayworker » 07.05.2021, 13:32

Das es mit Windows keine Probleme gab, ist so auch nicht korrekt. Die von Winzigweich mit 20H2 umgesetzten Sicherheitsfeatures sorgten nachweislich für schwerwiegende Probleme, erst nachdem die verkündete Zusammenarbeit zwischen VMware und M$ endlich greifbare Resultate erbrachte, änderte sich das etwas. Jedes neue Update sorgt aber an anderer Stelle für neuen Ärger.

Den von dir angesprochenen Bug kann im Grunde nur Ubuntu selber beheben oder du spielst manuell einen eigenen Kernel ein und mußt dann viele Abhängigkeiten auflösen. Daher dürfte die einzigste Möglichkeit im Abwarten bestehen oder du schreibst zumindest mal bei Ubuntu-Users mal ein Posting.

Guru
Beiträge: 2731
Registriert: 23.02.2012, 12:26

Re: Ubuntu 20.04 + vmWare WS 16.1.1 + LUKS volume -> crashes

Beitragvon ~thc » 07.05.2021, 13:55

Der Trigger wird durch den VMCI-Treiber in der VM ausgelöst:
https://communities.vmware.com/t5/VMware-Workstation-Player/VMWare-Player-crashing-on-Windows-Guest-Shutdown/m-p/1751650

Es gibt drei Workarounds:

1) Use a file system other than ext4 for holding the virtual machine files (like btrfs, xfs or jfs)
trade off: requires a separate partition just for the VM files (or a reformatting of the current one);

2) bindfs (fuse) mount the directory containing the virtual machine files on top of itself before turning on the virtual machine
trade off: a small hit in performance;

3) disable the vmci virtual hardware in the .vmx file
trade off: cannot use shared folders

Member
Beiträge: 4
Registriert: 06.05.2021, 16:57

Re: Ubuntu 20.04 + vmWare WS 16.1.1 + LUKS volume -> crashes

Beitragvon JoeMs2021 » 07.05.2021, 14:43

Dayworker hat geschrieben:Das es mit Windows keine Probleme gab, ist so auch nicht korrekt. Die von Winzigweich mit 20H2 umgesetzten Sicherheitsfeatures sorgten nachweislich für schwerwiegende Probleme, erst nachdem die verkündete Zusammenarbeit zwischen VMware und M$ endlich greifbare Resultate erbrachte, änderte sich das etwas. Jedes neue Update sorgt aber an anderer Stelle für neuen Ärger.

Den von dir angesprochenen Bug kann im Grunde nur Ubuntu selber beheben oder du spielst manuell einen eigenen Kernel ein und mußt dann viele Abhängigkeiten auflösen. Daher dürfte die einzigste Möglichkeit im Abwarten bestehen oder du schreibst zumindest mal bei Ubuntu-Users mal ein Posting.


Hehe, wegen Windows 10 bin ich ja abgesprungen. Das letzte Windows, das ich freiwillig verwendet habe, war Windows 7! Da gab es gefühlt überhaupt keine Probleme. Aber da man das offenbar zu uncool fand, beim Hersteller gereifte Software anzubieten, musste ich mir eindeutig was anderes suchen.

Member
Beiträge: 4
Registriert: 06.05.2021, 16:57

Re: Ubuntu 20.04 + vmWare WS 16.1.1 + LUKS volume -> crashes

Beitragvon JoeMs2021 » 07.05.2021, 14:45

~thc hat geschrieben:Der Trigger wird durch den VMCI-Treiber in der VM ausgelöst:
https://communities.vmware.com/t5/VMware-Workstation-Player/VMWare-Player-crashing-on-Windows-Guest-Shutdown/m-p/1751650

Es gibt drei Workarounds:

1) Use a file system other than ext4 for holding the virtual machine files (like btrfs, xfs or jfs)
trade off: requires a separate partition just for the VM files (or a reformatting of the current one);

2) bindfs (fuse) mount the directory containing the virtual machine files on top of itself before turning on the virtual machine
trade off: a small hit in performance;

3) disable the vmci virtual hardware in the .vmx file
trade off: cannot use shared folders


Klasse, vielen Dank für diese Infos. Wenn die auslösende Komponente zu vmWare gehört, kann man ja hoffen, dass es irgendwann eine Lösung dafür gibt, oder? Den Wechsel auf btrfs könnte ich mir vorstellen, es gibt von dem Volume zum Glück immer aktuelle Backups.

Noch mal danke an alle, Ihr habt mir weitergeholfen!


Zurück zu „VMware Workstation und VMware Workstation Pro“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 12 Gäste