search

vmware / open-vm-tools

Official repository of VMware open-vm-tools project
http://sourceforge.net/projects/open-vm-tools/
2.26k stars 427 forks source link

File copy+paste from Fedora 33 -> Fedora 34 == target VM dies #520

Open shoffmeister opened 3 years ago

shoffmeister commented 3 years ago

I suspect that this issue might be a problem with VMWare Workstation Player 15.5.6 build-16341506 on an enterprise-managed Windows 10, 64-bit (Build 18363.1379) 10.0.18363, but there is also a open-vm-tools component to it:

//exp: works (and this works for, e.g., clipboard text or xml) //act: Fedora 34 VM literally disappears out of existence - no host dialog such as "as I died" or anything, it just disappears

Relevant content from the Fedora 34 VM vmware.log:

2021-06-13T10:38:57.280+02:00| vmx| I005: GuestRpcSendTimedOut: message to toolbox-dnd timed out.
2021-06-13T10:39:05.392+02:00| vmx| I005: GuestRpc: Got RPCI vsocket connection 113554, assigned to channel 1.
2021-06-13T10:39:06.268+02:00| vmx| I005: Guest: toolbox-dnd: Version: 11.2.5.26209 (build-17337674)
2021-06-13T10:39:06.269+02:00| vcpu-2| W003: GuestRpc: application toolbox-dnd, changing channel 65535 -> 1
2021-06-13T10:39:06.269+02:00| vcpu-2| I005: GuestRpc: Channel 1, guest application toolbox-dnd.
2021-06-13T10:39:06.271+02:00| vcpu-2| I005: TOOLS: appName=toolbox-dnd, oldStatus=0, status=1, guestInitiated=0.
2021-06-13T10:39:06.288+02:00| vmx| I005: DnDCP: set guest controllers to version 4
2021-06-13T10:39:06.291+02:00| vmx| I005: DnDCP: set guest controllers to version 4
2021-06-13T10:39:06.291+02:00| vmx| I005: DnDCP: set guest controllers to version 4
2021-06-13T10:39:06.574+02:00| vmx| I005: DnDCP: set guest controllers to version 4
2021-06-13T10:39:19.660+02:00| vmx| I005: Progress -1% (msg.HGFileCopy.preparewrite)
2021-06-13T10:39:19.661+02:00| vmx| I005: HGFileCopy_SendFiles: Cannot determine C:\Users\myuser\AppData\Local\Temp\vmware-MYUSER\VMwareDnD\73fe8753\myfile.tar.gz file type

In my case, myfile.tar.gz has a size of 1046 bytes (i.e. it is tiny)

The failure mode, IMHO, points to something inside the VMware host - why else would the VM go "poof" and obliterate itself? - but perhaps the vmtools contribute.

FWIW, I have no easy means to switch to a(ny) different version of VMware Workstation Player - neither update nor upgrade.

gauravjvmw commented 3 years ago

Hi, We will check it on our end. And will post the update here.

Thanks.

gauravjvmw commented 3 years ago

@shoffmeister If possible can you please share latest Vmware logs for both the guests after retrying the activity once. Logs (UI Log file and VM Log file for respective guests) can be found by Clicking on Help-> About Workstation. You can check the VM location & logs in the same way for both the guests.

gauravjvmw commented 3 years ago

In case if possible on your side, please set debugging level to Full. It should be present VM > Settings, click the Options tab, and select Advanced, you will find setting option there. On guest side you can enable logging using https://kb.vmware.com/s/article/1007873 https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/workstation-pro-16-user-guide.pdf : Search for Gathering Debugging Information. Also let us know which open-vm-tools version you are using, does it came as a part of OS or you installed something by yourself?

shoffmeister commented 2 years ago

@gauravjvmw I have found another reproducer (having lost the original one) for the virtual machine dying on tools copy&paste.

The (very small and short) attached video https://user-images.githubusercontent.com/3868036/156727247-d4ef8930-177a-4281-9ea2-95f4150326e3.mp4 shows a screen recording of what is happening:

On the left-hand side you see VMware Workstation Player 15.5.7 build-17171714, running a Linux Fedora 35 guest, with distribution-provided open-vm-tools (11.3.0-2.fc35, VMware Tools daemon, version 11.3.0.29534 (build-18090558)). The window is plain KDE Dolphin, with the directory going to a remote system, fish:///

On the right-hand side, you see an empty Microsoft Windows 10 Enterprise Explorer window.

The video demonstrates that simply "copy" inside KDE on "timestamp.tar.gz" and then "paste" inside the Windows Explorer window makes the VM disappear ("go poof"). Notice that exactly at the time of dying, there is an interesting screen artefact popping up image with that white rectangle - much like a dying gasp, issued by the host-side process.

The file I show trying to move is timestamp.txt.gz at a whopping size of 40 bytes. There is a commonality, IIRC, with my previous scenario: that was also a tiny .gz, but there I did not go through fish:// on a remote box, that was strictly local content.

I would not want to rule out that ".gz" is the problem, with heaps of defensive tools (antivirus, endpoint protection, ...) running on my managed Windows system. One hypothesis could be that antivirus might interfere. Let me put this hypothesis in doubt immediately: I copied the that file (inside the guest) locally, then did the copy&paste to the host dance again - this time successfully.

FWIW, on the guest, I had enabled VMware Tools logging

[logging]
log = true

vmtoolsd.level = debug
vmtoolsd.handler = file+
vmtoolsd.data = /tmp/vmtoolsd-${USER}.log

(the file+ on this required, because the VM totally dying would overwrite any previously collected logs upon restarting the VM...)

Now, I am not surprised to report that the VMware tools logs on the guest do not contain anything useful - because the failure mode suggests that the VM gets the lights snuffed out from the outside (effectively total host vm crash / loss of virtual power), see at the end of this comment for guest /var/log/messages and the timeline there.

I unfortunately do not know how to enable full debug level for the host (i.e. VMware Workstation Player on Windows).

Mar  4 09:18:55 fedora audit: BPF prog-id=0 op=UNLOAD
Mar  4 09:18:55 fedora audit: BPF prog-id=0 op=UNLOAD
Mar  4 09:19:06 fedora kwin_x11[1761]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 40883, resource id: 56623112, major code: 18 (ChangeProperty), minor code: 0
Mar  4 09:19:38 fedora kioslave5[2578]: Qt: Session management error: networkIdsList argument is NULL
Mar  4 09:20:00 fedora kwin_x11[1761]: kwin_core: XCB error: 152 (BadDamage), sequence: 46092, resource id: 16785010, major code: 144 (DAMAGE), minor code: 2 (Destroy)

<!----- lights are apparently snuffed out here ------> 

Mar  4 09:29:28 fedora kernel: Linux version 5.16.11-200.fc35.x86_64 (mockbuild@bkernel01.iad2.fedoraproject.org) (gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9), GNU ld version 2.37-10.fc35) #1 SMP PREEMPT Wed Feb 23 17:08:49 UTC 2022
Mar  4 09:29:28 fedora kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.16.11-200.fc35.x86_64 root=UUID=93385cec-9420-4608-82b9-3aa9779991e5 ro rootflags=subvol=root rhgb quiet
Mar  4 09:29:28 fedora kernel: Disabled fast string operations
Mar  4 09:29:28 fedora kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Mar  4 09:29:28 fedora kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Mar  4 09:29:28 fedora kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Mar  4 09:29:28 fedora kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Mar  4 09:29:28 fedora kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
Mar  4 09:29:28 fedora kernel: signal: max sigframe size: 1776
Mar  4 09:29:28 fedora kernel: BIOS-provided physical RAM map:
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] usable
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] reserved
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000bfecffff] usable
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x00000000bfed0000-0x00000000bfefefff] ACPI data
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x00000000bfeff000-0x00000000bfefffff] ACPI NVS
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x00000000bff00000-0x00000000bfffffff] usable
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x00000000fffe0000-0x00000000ffffffff] reserved
Mar  4 09:29:28 fedora kernel: BIOS-e820: [mem 0x0000000100000000-0x000000083fffffff] usable
Mar  4 09:29:28 fedora kernel: NX (Execute Disable) protection: active
Mar  4 09:29:28 fedora kernel: SMBIOS 2.7 present.
Mar  4 09:29:28 fedora kernel: DMI: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
Kareto commented 2 years ago

try to execute this on terminal and try again

vmware-user-suid-wrapper
shoffmeister commented 2 years ago

Right now I do not have access to the system to reproduce. I do know though, that I was always and religiously manually running vmware-user-suid-wrapper after every KDE desktop login. (Reason being systemd and VMware start up service and KDE and what not - https://bugzilla.redhat.com/show_bug.cgi?id=1953472)