Hide Forgot
Description of problem: Both "vmware-xferlogs enc /" and "vmtoolsd -g /" seem to crash at least on systems which are not VMware guests. Of course there's no real point to run these on non VMware guest but even so they should not crash. Version-Release number of selected component (if applicable): open-vm-tools-10.0.5-2.el7.x86_64
vmtoolsd is normally run from a systemd service, and the systemd service is protected by: ConditionVirtualization=vmware so I don't think that is an issue. (It's a problem if vmtoolsd is starting up automatically on a non-VMware guest). I'm not familiar with what vmware-xferlogs does, but can you provide a stack trace of where it is crashing please.
Created attachment 1214265 [details] core.xz
Thread 1 (Thread 0x7f586dc71880 (LWP 928)): #0 0x00007f586d7e684c in Backdoor_InOut () from /var/tmp/usr/lib64/libvmtools.so.0.0.0 #1 0x0000000080000000 in ?? () #2 0x00007f586d7fdac5 in Message_OpenAllocated () from /var/tmp/usr/lib64/libvmtools.so.0.0.0 #3 0x00007f586d804a07 in RpcOut_startWithReceiveBuffer () from /var/tmp/usr/lib64/libvmtools.so.0.0.0 #4 0x00007f586d804c01 in RpcOutSendOneRawWork () from /var/tmp/usr/lib64/libvmtools.so.0.0.0 #5 0x00007f586d804fcf in RpcVMX_LogV () from /var/tmp/usr/lib64/libvmtools.so.0.0.0 #6 0x00007f586d805089 in RpcVMX_Log () from /var/tmp/usr/lib64/libvmtools.so.0.0.0 #7 0x00007f586dc89065 in main () Not especially surprising that it crashes when touching the VMware backdoor port (https://sites.google.com/site/chitchatvmback/backdoor) It might help if these tools checked for VMware virtualization being present before trying to touch that port.
"vmware-xferlogs enc" transfers support logs to VMware HV platform and "vmtoolsd -g" is running "vmtoolsd" in debug mode. There is no reason for someone to run these commands on non-VMware platform. However, I agree that we could enhance these to fail gracefully with an error message instead of crashing. I will file a VMware internal bug to fix these in the next release.
I test guest which run on Hyper-V, after run "vmware-xferlogs enc /"and "vmtoolsd -g /" the result is as below, [root@rhel7 ~]# vmware-xferlogs enc / Segmentation fault (core dumped) [root@rhel7 ~]# vmtoolsd -g / Aborted (core dumped) [root@rhel7 ~]#
This is not fixed yet. Could you please also provide the core dumps with matching debug binaries?
(In reply to Ravindra Kumar from comment #7) > This is not fixed yet. Could you please also provide the core dumps with > matching debug binaries? Hi Ravindra, I know this issue is not fixed yet, I just want to record the test result, the attachment is the core dumps, I am not sure where is the debug binaries,could you provide the path? thanks very much! ldu
Created attachment 1267213 [details] core dump
(In reply to ldu from comment #8) > the attachment is the core dumps, I am not sure where is the debug > binaries,could you provide the path? Debug binaries would be there in debuginfo package. I think Richard can help you with getting a useful backtrace.
(In reply to Ravindra Kumar from comment #5) > "vmware-xferlogs enc" transfers support logs to VMware HV platform and > "vmtoolsd -g" is running "vmtoolsd" in debug mode. > > There is no reason for someone to run these commands on non-VMware platform. > However, I agree that we could enhance these to fail gracefully with an > error message instead of crashing. > > I will file a VMware internal bug to fix these in the next release. Hi Ravindra, What's the internal PR? In the future, please post internal PR# in comments so other people can find the bugs.
(In reply to John Savanyo from comment #11) > What's the internal PR? It is 1757250. > In the future, please post internal PR# > in comments so other people can find the bugs. Yes, that's a good idea, I already started doing that recently.
I assigning bug to myself. Ravindra please continue to work this issue.
Hello, Do we any update on this issue ? Was it fixed in open-vm-tools-10.2.5-3.el7 ?
Hi JinYan, Could you help check the VMware internal bug 1757250 has been fixed or not? Thanks very much! Lili Du
(In reply to ldu from comment #17) > Hi JinYan, > Could you help check the VMware internal bug 1757250 has been fixed or not? > Thanks very much! > > Lili Du Hi Lili, The status of the VMware internal bug is not resolved as fixed yet.
Closing as won't fix. If the resolution or status should be different, please change. Thanks.
Clearing need-info to eliminate reminders.
A fix for this is in the open-vm-tools 11.2.0 release. commit 1f66f283c20f7f5cd154ca34c33e3e145659916a Date: Fri Sep 11 12:11:05 2020 -0700 Ensuring vmtools utilities are only used in a VMware virtual environment. Several utilities do not check that their running environment is in a VMware hypervisor. Add checks and generate error messages if the running environment is a physical machine. Some makefiles were altered o resolve dependency issues.
(In reply to John Wolfe from comment #21) John is this an issue in all open-vm-tools revs up to 11.2.0?
(In reply to Cathy Avery from comment #22) > (In reply to John Wolfe from comment #21) > > John is this an issue in all open-vm-tools revs up to 11.2.0? Yes Cathy, this problem is an issue in all open-vm-tools releases prior to 11.2.0. As reported in description, there is really no reason to run these commands if not on a VMware guest. The fix is to check for the presence of a VMware hypervisor before attempting to access the backdoor channel. The following commands have been updated in 11.2.0 vmtoolsd -g vmware-namespace-cmd vmware-rpctool vmware-xferlogs vmware-alias-import