banackm's Posts

Are those the logs from when it failed?  Or was that from a time when it was still working? The error message you're describing normally means the UI couldn't talk to the VM anymore, which usually means the VM crashed, but I don't see that in your logs. It's possible things are going wrong very early in PowerOn and it hasn't saved the logs into the VM folder yet, in which case you can check for logs in /tmp/vmware-username/ . Can you double-check that for me and get me a failing log or else confirm those are the newly generated logs when you hit this?

That configuration will change how we draw the final contents into the window, but not how the actual graphics rendering is done. So on your card, the rendering is still being done on your GPU with Vulkan, and then when we have to draw into the window we will use X11 for the last step (usually called "Presentation", hence the config option name). The cost is proportional to the display size and the frame rate of the workload, so how much of a performance hit that is will depend on your system and workload.  Applications that are running very graphics heavy workloads and already getting low frame-rates probably won't notice at all, whereas as the graphics workload gets lighter and the resolution/FPS increases, there will start being more of a difference between the two modes. On my system, I can't tell the difference between the two paths up until my graphics workload gets too high and my host GPU gets saturated, and then my performance falls off a cliff.  So if your application has a frame-rate limiting option, you could try lowering the FPS and ironically your performance might improve.  But the difference between the two paths might be greater on lower-end GPUs?

You could try setting these config options: mks.enableX11Presentation=TRUE mks.enableVulkanPresentation=FALSE That will force us to draw the window using X11 instead of Vulkan, which is normally less performant, but might work better on some setups? If someone can post a vmware.log and mksSandbox.log where this is hitting our graphics team can take a look.

You appear to be hitting a timeout where the host graphics system appeared unresponsive for too long.  It's not clear how that would be related to the guest OS sleep state, but we're trying to reproduce this internally. In the meantime, if you want to experiment with keeping your 3D graphics enabled, you might try setting the following config option in your vmx file: mks.sandbox.socketTimeoutMS = 200000 That will double the default timeout and make Workstation wait about 3 minutes until declaring a timeout.  You could adjust that number up if it still wasn't helping, but that's already a long time for a graphics glitch.  The value is in milliseconds, and the risk of setting it too high is that will take longer for Workstation to detect the hang, which might mean you're unable to ungrab or power off the VM until the timeout is reached.

We've reproduced this in-house, and are seeing what we can do. The only work-around I can suggest at the moment is that if you lower the polling rate of your mouse it seems to get better or go away completely for us.

Ah sorry, this would be the Logitech Mouse configuration on the host.  We don't actually pass the mouse through to the Guest, we just rely on the Host Operating System sending us the input events, and then we have our own virtual mouse device with our own driver that runs in the Guest.  They sometimes have a setting that works as a compatibility mode, and injects different events, or injects them more normally.  But every mouse software I've looked at works differently. As an advanced option, if you had a second mouse, you can sometimes pass through one mouse completely into the Guest (so the Host can't use it at all), and then you can use the complete 3rd party mouse driver/software, but that's an unusual configuration.

Do you have Tools installed into the VM? And if you take your mouse to the edge of the VM console window, does it get clipped at the edge, or does it "leak" out of the VM window onto the host? If it's getting clipped, then you're not getting cursor acceleration all the way from the guest.  To get that working you have to have VMware Tools installed in the guest, although odd things like an intermediate VNC/RDP session, or a cursor that's too large can still trip it up. The extended monitor link is weird though... There might be a host graphics issue in play.  Do you see this on VMs with both 3D graphics enabled and disabled?

Yeah, that looks like something is hanging our input processing.  As you noted, it might be related to the sheer amount of mouse events coming in from your high-end mouse. What does Task Manager show over this period?  Is there a spike in CPU usage for VMware?  Or which processes get bogged down during this period?

Have you tried the open-vm-tools ?  That's our Open Source version of VMware Tools, and you can normally install it through your distro's package manager, rather than trying to use our installer scripts.  I think for modern Linux distributions that's generally what we recommend people use over the ISO-based installer.

The problem with most custom mice inter-operating with VMware Workstation/VMRC is usually that they have custom software running into the session that injects mouse events themselves into the foreground application, rather than sending it through the standard Windows input stack.  This doesn't interact well with how VMware gets mouse/keyboard input. You can sometimes configure application-specific settings, launch the Logitech software as Administrator, otherwise configure the mouse software to get it to work, but it's really hit and miss.

I'm a little unclear what prevents you from putting all the workbooks on your screen, but it sounds like either your Guest resolution is too small, or else the Guest DPI is turned up too high. You can make the Guest larger by increasing the window size, or putting the Guest into Fullscreen mode if "Autofit" is turned on. The Guest DPI controls how many pixels are used to render fonts of a given size.  So if this is turned up, all your fonts are bigger and take up more rom on your screen. This can be adjusted from inside the guest under the Display settings.  (This image might help: https://www.tenforums.com/attachments/tutorials/118914d1485629514-change-dpi-scaling-level-displays-windows-10-a-dpi_in_settings-1.png?s=bf1a16485da214d47587ef6126751924 ).

I'm not an expert at how guest main memory is managed, and it gets pretty complicated quickly, but depending on what precisely your system monitors are using, it's possible that they're over-estimating the amount of memory that Workstation is actually using. We use a variety of tricks to manage host memory usage, including swapping portions of it out to disk when the host is under pressure.  So just because we're using that much memory when your system has available memory doesn't mean that we need that much if the host is under load. You might enjoy the "Memory Resources in Workstation and Virtual Machines" section of the Performance Best Practices for VMware Workstation .  It's a little old, but I think most of it is still accurate.

Enabling 3D graphics unfortunately uses up a large amount of host memory, and newer versions of Workstation with the "GPU Sandbox Renderer" feature started using more host memory for this than previous versions, which I think is what you're seeing here.  This jump in memory usage is definitely something we hope to optimize in future releases. The setting for "Graphics Memory" limits the amount of graphics resources that the guest is allowed to use, but that value includes memory allocations coming from the guest, host, and graphics card.  So it doesn't directly translate into host memory usage, and not all of the memory that the guest is allowed to use for graphics is allocated when the guest starts running.  You can see this if you start launching large graphics applications in your guest, where you should see the consumed memory in the vmx process increase.  So turning the limit up should let your guest graphics applications be able to use larger amounts of graphics resources inside the guest, which should hopefully translate into higher performance for memory constrained workloads.

I'm not sure exactly where you're seeing that reported, but there's different kinds of graphics memory. Physical graphics cards have memory as part of the card, that's commonly called "on-board" or "Dedicated" graphics memory, and then they can also access system memory for some graphics operations, which is commonly referred to in Windows as "Shared Memory". For new, modern VMs, VMware's virtual graphics device functions more like an integrated graphics card, in that it primarily uses shared system memory, rather than on-board dedicated memory. So if you turned up the "Graphics Memory" on the VM in the Workstation UI, the "4MB" value you're seeing is probably the dedicated memory in the virtual PCI-card of our graphics device, which isn't actually used for anything after the guest has finished booting and the graphics driver is loaded. Whereas the "3000MB" value is probably the amount of system-memory that your guest applications are allowed to use for graphics operations, which is actually the amount of graphics resources the application can create. So that sounds correct to me. I'm not sure why you're having Chrome/Photoshop problems though... Can you post a vmware.log file for us to look at?

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.

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.

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.