VMWare Workstation 16 - mksSandbox log

kasper · ‎09-30-2020

For prior versions of workstation going to settings / options / advanced and selecting 'none' for 'gather debugging info'

seemed to stop most logging of the guest.

Now in version 16 a new log file appears - mksSandbox.

How do you disable logging for it?

Thank you,

Stan

banackm · ‎09-30-2020

The "Debugging Info" field controls whether you're running our fully-optimized hypervisor, or the less-optimized one that has extra debugging checks and logging. If you check our installed Workstation folder, we actually ship multiple separate "vmx" binaries, one for each mode. We similarly ship multiple "mksSandbox" binaries, and the "Debugging" option controls which one of those gets launched the same way.

So there should be a much reduced rate of logging to the disk when the "None" option is set in both the "vmware.log" and the "mksSandbox.log". For the most part though, the entries in the mksSandbox.log are all things that used to be printed into the vmware.log that are just now being printed into a different file, so the overall amount of logging (as far as the total bytes that hit the disk) shouldn't be substantially different from prior versions.

But if your concern is the actual presence of the file itself and not the amount of logging, I'm not aware of a way to just turn off the creation of that file. It should get created and rotated just like the vmware.log files no matter what "Debugging" options are selected.

kasper · ‎10-01-2020

Thank you for the response. It would be nice that when 'none' is selected for logging

then that means no log file. So much for the meaning of 'none'.

So when I look at the log file and see messages like 'techpreview.cfg not found' I have

to wonder what is going on here. I realize this is a new release and the sandbox

is a substantial change. But more and more I feel like being on the bleeding edge.

banackm · ‎10-01-2020

As far as I know the option should consistently be called "Gather Debugging Information", not specifically a reference to logging. If there's somewhere we've documented that it's explicitly a logging option, let me know because that's probably a documentation or UI bug.

I'm not sure exactly what "techpreview.cfg" message you're seeing, but if it says something like:

DictionaryLoad: Cannot open file techPreview.cfg

That should be a harmless message. Our log-files aren't really intended to be fully user-readable, so most of the message in there are aimed at our developers to help troubleshoot problems.

bluefirestorm · ‎10-01-2020

I see the same things in version 15.5.6.

vmx| I005: DictionaryLoad: Cannot open file "/etc/vmware/vsphereFeatures/techPreview.cfg": No such file or directory.

vmx| I005: [msg.dictionary.load.openFailed] Cannot open file "/etc/vmware/vsphereFeatures/techPreview.cfg": No such file or directory.

vmx| I005: FeatureStateLib: Error while loading tech preview config file: /etc/vmware/vsphereFeatures/techPreview.cfg, using default (disabled) for all Tech Preview features.

I know software development can be messy. But log entries like this seem to indicate/suggest code for one development track is getting mixed with another.

I understand that is harmless. And probably the development team is not mixing feature code.

But it is a bit like some people want to eat meat but they don't want necessarily want to see all the processes how it got to their plate from the farm.

banackm · ‎10-02-2020

I've filed an internal bug report to raise your concerns with the appropriate development team.

In the meantime, if you don't want to see what's going on under the hood, you might consider avoiding reading the log files? There's no way we're going to be able to remove all messages that users might find alarming and still provide enough information to our developers to help customers work through field issues.

bluefirestorm · ‎10-02-2020

Don't get me wrong. I don't mind looking at log files and seeing what's under the hood.

But when log files hint at code from different development tracks are getting mixed even though how harmless, it is not a good look to outsiders/users. As what it did giving OP the impression that it is "bleeding edge". I also concur with him that when log files are "off" that it should be "off". For this particular thread topic, the mks-sandbox.exe cannot seem to function without one.

I understand how software development projects go. Show me a software development project that does not get messy. :smileylaugh: They all are; they just differ in the degree of messiness.

I do appreciate the VMware team's work. It is very complex software.

kasper · ‎10-10-2020

Thank you for reply. I believe a requirement for quality software should

have the option to turn any/all logging/debugging off. Hopefully in the

next update to Workstation 16 there will be an option to do so.

jen2 · ‎01-26-2021

Please consider an option to disable UI and Unity-helper logs, they can still be optional, any wants to enable them will still can do it.

Thanks

Pickwick81 · ‎06-10-2021

@banackm wrote:
As far as I know the option should consistently be called "Gather Debugging Information", not specifically a reference to logging. If there's somewhere we've documented that it's explicitly a logging option, let me know because that's probably a documentation or UI bug.

I can't find any docs about configuring mksSandbox.log at all, I would like to be able to dot he same like with the following statements:

log.fileName = "D:\VMware\tp-test-win10\Logs\vmware.log"
vix.log.fileName = "D:\VMware\tp-test-win10\Logs\vix.log"
vmx.log.fileName = "D:\VMware\tp-test-win10\Logs\vmx.log"

Nothing I tried works for mksSandbox.log:

mksSandbox.log.fileName = "D:\VMware\tp-test-win10\Logs\mksSandbox.log"
mksSandbox.logFileName = "D:\VMware\tp-test-win10\Logs\mksSandbox.log"
mks.log.fileName = "D:\VMware\tp-test-win10\Logs\mksSandbox.log"
mks.logFileName = "D:\VMware\tp-test-win10\Logs\mksSandbox.log"

Please make such configs available and/or document them properly.

jen2 · ‎06-10-2021

@Pickwick81 There are no documentations at all regarding logs files. All these logs are not optional, I doubt that the average user will be aware of their existence.

In the folder vmware-%username% you will find hundreds of unnecessary log files for the user interface and the unity helper, with names vmware-ui-xxxx.log and vmware-unity-helper-xxxx.log. Useless and the same logs each time
in the Folder vmware-SYSTEM you will find the USB log file. BTW this folder can't be accessed, you have to have system privilege to access the folder, which makes you wonder why there are logs there!
and the vminst.log which keeps increasing in size https://kb.vmware.com/s/article/71332
The mksSandbox.log, which will force 3 identical versions, same logs each time and useless.

These Logs can be useful when there are errors, but on daily usage they are useless and will only consume resources. They should be optional.

I really hope that the developer will make the logs optional, an expert and an average can disable them, and when needed they can be enabled again.

Paul_Coddington · ‎07-14-2021

As a side note, the mksSandbox log gets created in a spurious location if there are Unicode characters in the path name of the Virtual Machine. Other logs do not have this problem.

For years I have habitually distinguished special folders with preceding full stops and lower case to sort them to the top of the Explorer listing and distinguish them from project folders (eg: .templates, .backups, .output, etc). Since the additional of WSL, the meaning of proceeding full stop in file names is now "hidden" in the Linux context, so I have started experimenting with other characters such as Unicode "Middle Dot".

Unfortunately, this upsets the mksSandbox log which creates a spurious new path for itself where the "middle dot" is preceded by a spurious "Â" character (Â as in "Angstrom").

Although this might seem an odd edge case, it might be prudent to make sure that VMware is robust in a Unicode file system by ensuring it handles Unicode characters in paths correctly (as this will be important in countries that do not speak English).

In the meantime, I will drop preceding characters altogether and resort to square brackets for special folders, although it is not as "clean" in appearance.