lucvdv-aleacsys's Posts

Workstation Pro 17, linux host, serial ports USB-RS232 adpter don't work

by Contributor in VMware Workstation Pro Discussions
‎02-25-2023 03:20 AM
‎02-25-2023 03:20 AM
Has anyone succeeded in getting VMWare Workstation (Pro 17) to recognize /dev/ttyUSB0 (a USB-to-serial adapter) as a serial port? My machine has no serial ports, so I am trying to use a USB-to-seria... See more...
Has anyone succeeded in getting VMWare Workstation (Pro 17) to recognize /dev/ttyUSB0 (a USB-to-serial adapter) as a serial port? My machine has no serial ports, so I am trying to use a USB-to-serial adapter. It is detected and should be working as ttyUSB0. However, VM settings for the serial port show no serial ports at all in the dropdown. I found an old post (from 2013) that gives a solution, but that doesn´t seem to work anymore. The VM boots, no warnings about serial port not found, but there is no communication.   When I apply that solution, boot the VM, start an application that uses the port, and then check if VMWare is using the port (sudo ls -l /proc/[0-9]*/fd/* | grep tty), no process is  using ttyUSB0, all it shows is the UI using /dev/tty0 and for some reason Google Chrome is using /dev/tty2.   BTW, the guest doesn´t support USB, so I can´t hook it up there.

Re: VMware tools with Ubuntu 22,04 copy and paste not working properly

by Contributor in VMware Workstation Pro Discussions
‎02-20-2023 04:47 AM
‎02-20-2023 04:47 AM
Tried unchecking/rechecking the options too etc., and also this that I found somewhere else. gsettings set org.gnome.nautilus.preferences use-experimental-views false It didn't help.  

Re: VMware tools with Ubuntu 22,04 copy and paste not working properly

by Contributor in VMware Workstation Pro Discussions
‎02-20-2023 04:30 AM
‎02-20-2023 04:30 AM
This problem seems to be old, I had it at least in Ubuntu 22.04, 20.04, in VMWare 17, previously 16, and maybe 15 too (always the same VM, I've been using it forever over different upgrades). I got ... See more...
This problem seems to be old, I had it at least in Ubuntu 22.04, 20.04, in VMWare 17, previously 16, and maybe 15 too (always the same VM, I've been using it forever over different upgrades). I got 2 distinct situations plus an observation. Sometimes I got a "no drop" mouse pointer. That's clear enough, no drag and drop. Sometimes I got a regular drag pointer, but the files didn't appear after being dropped. Sometimes, but not always, just restarting the drag from the start a few times changes it from 1 to 2. Today I discovered that in case 2, the files *are* copied to the VM, just not moved to the right location. All files I ever dropped-and-failed were in ~/.cache/vmware/drag_and_drop/xxxxxx/ in the VM -- it went back to 2019. xxxxxx is a temp name, a random string of 6 letters and digits. Just sort the drag_and_drop directory by Modified time in Files to find the most recent one. ".cache" is hidden, don't forget to turn on 'show hidden files'. It might also be a good idea to clear the directory out from time to time, especially if you have been trying again and again to drop some large files in there, as I had -- EDIT -- Sorry for mixing this into a "copy and paste" thread, I thought I was replying in another thread I read 15 minutes earlier. 

Re: 1 minute delay booting VM after upgrade from WS Pro 16 to 17

by Contributor in VMware Workstation Pro Discussions
‎01-05-2023 07:09 AM
1 Kudo
‎01-05-2023 07:09 AM
1 Kudo
RDPetruska, I still didn't find the threads you mentioned, but now that I could create good as well as bad new VM's it was just a matter of comparing VMX files side by side. This line is the culprit... See more...
RDPetruska, I still didn't find the threads you mentioned, but now that I could create good as well as bad new VM's it was just a matter of comparing VMX files side by side. This line is the culprit: mks.enable3d = "TRUE" Remove it from the Ubuntu/64 vmx file or change to "FALSE", and the problem goes away. As far as I could tell in a minute, everything in the VM still works.

Re: 1 minute delay booting VM after upgrade from WS Pro 16 to 17

by Contributor in VMware Workstation Pro Discussions
‎01-05-2023 06:44 AM
‎01-05-2023 06:44 AM
Thanks, I had tried to look for something like that but didn't find anythin gyet. In the mean time I have been experimenting some more. I created new VM's, selecting different target OSs, each time... See more...
Thanks, I had tried to look for something like that but didn't find anythin gyet. In the mean time I have been experimenting some more. I created new VM's, selecting different target OSs, each time just leaving the virtual disk empty and starting them by "boot to firmware". Of those I tried so far, only "Linux / Ubuntu 64-bit" had the problem. Other settings I tried that didn't have the problem: "Other / DOS", "Linux / Debian 11.x", were fine. Changing the target OS after creating the VM had no effect, once bad it remained bad.  

Re: 1 minute delay booting VM after upgrade from WS Pro 16 to 17

by Contributor in VMware Workstation Pro Discussions
‎01-05-2023 05:41 AM
‎01-05-2023 05:41 AM
I don't get it anymore I created a new VM with the same configuration and attached the original VM's virtual disk to it: exactly the same. That together with the Windows and Debian VMs running O... See more...
I don't get it anymore I created a new VM with the same configuration and attached the original VM's virtual disk to it: exactly the same. That together with the Windows and Debian VMs running OK would make you believe it's something on that virtual disk. But "boot to firmware" does it too, it takes half a minute before the BIOS screen appears, and it takes 1-2 seconds and sometimes longer to react to every keypress. So I created a new VM, set the OS type to "Ubuntu 64 bit", did not install an OS, just left the disk empty, and did "Boot to firmware". Again the same: half a minute before the BIOS screen appeared, and reaction to keypresses takes seconds. Powered it off, changed the OS type from Ubuntu 64 bit to Debian 10.x 64 bit, and STILL the same. But I have an existing Debian 10.x VM that boots just fine, and doesn't seem to be affected by this problem at all.

Re: 1 minute delay booting VM after upgrade from WS Pro 16 to 17

by Contributor in VMware Workstation Pro Discussions
‎01-05-2023 04:52 AM
‎01-05-2023 04:52 AM
Done some experimenting with CPU, RAM, display (vga) configuration etc., to no avail. Even in a new full clone it remains the same. After some reconfig in the guest itself, I now see that it *does* ... See more...
Done some experimenting with CPU, RAM, display (vga) configuration etc., to no avail. Even in a new full clone it remains the same. After some reconfig in the guest itself, I now see that it *does* start booting the OS, but there seems to be something completely off with timing. The GRUB boot menu appears after reconfiguring it as not hidden, but the timeout ("automatically in n seconds") counts down at about 1 second per every 15-20 seconds real time. Once it reaches zero and starts booting the real OS, speed is normal.   It didn't do this de last time I ran that VM in Workstation 16, yet I have other VM's (Debian instead of Ubuntu) that also use grub as boot loader and do not exhibit this behavior.

Re: 1 minute delay booting VM after upgrade from WS Pro 16 to 17

by Contributor in VMware Workstation Pro Discussions
‎01-05-2023 02:26 AM
‎01-05-2023 02:26 AM
I upgraded the virtuial hardware version from v14 to v17, the problem remains.

1 minute delay booting VM after upgrade from WS Pro 16 to 17

by Contributor in VMware Workstation Pro Discussions
‎01-05-2023 01:56 AM
‎01-05-2023 01:56 AM
I just upgraded from Workstation Pro 16 to 17. I only tested 2 VM's so far, one (Ubuntu 22.04) has this problem, the other (Windows 11) does NOT. When the Ubuntu VM boots, after the VMWare logo dis... See more...
I just upgraded from Workstation Pro 16 to 17. I only tested 2 VM's so far, one (Ubuntu 22.04) has this problem, the other (Windows 11) does NOT. When the Ubuntu VM boots, after the VMWare logo disappears, the screen remains black, with no disk or cpu activity to speak of, for a minute. Then the OS starts booting, and from there on everything runs as smooth as it did in version 16. Host: Core I9 9th generation (8 cores + hyperthreading), 32 GB RAM, Windows 10 22H2 Business VM: Ubuntu 22.04 (originally 20.04, upgraded in the VM long before the Workstation upgrade from 16 to 17); 8 GB RAM, 8 cores (ie all those from the host but not counting HT, this never was a problem for the host with v16). Monitoring the logfile during boot, this is where the delay occurs: 2023-01-05T09:43:00.341Z In(05) vcpu-0 AHCI-USER: Already in check condition 02 3a 00 2023-01-05T09:43:09.372Z In(05) vmx VNET: MACVNetLinkStateTimerHandler: 'ethernet0' state from 1 to 5. 2023-01-05T09:43:10.176Z In(05) vcpu-0 SVGA: FIFO is already mapped 2023-01-05T09:43:10.176Z In(05) svga SVGA enabling SVGA 2023-01-05T09:43:10.176Z In(05) svga SWBScreen: Screen 0 Destroyed: xywh(0, 0, 720, 400) flags=0x3 2023-01-05T09:43:10.178Z In(05) svga SVGA-ScreenMgr: Screen type changed to RegisterMode 2023-01-05T09:43:10.178Z In(05) svga SWBScreen: Screen 1 Defined: xywh(0, 0, 640, 480) flags=0x2 2023-01-05T09:43:53.110Z In(05) vmx GuestRpcSendTimedOut: message to toolbox-dnd timed out. 2023-01-05T09:44:08.838Z In(05) svga SVGA disabling SVGA 2023-01-05T09:44:08.838Z In(05) svga SWBScreen: Screen 1 Destroyed: xywh(0, 0, 640, 480) flags=0x2 2023-01-05T09:44:08.844Z In(05) svga SWBScreen: Screen 0 Defined: xywh(0, 0, 720, 400) flags=0x3 2023-01-05T09:44:09.658Z In(05) vcpu-0 Syncing WHP TSCs took 93 us. Threshold is 1000 us. 2023-01-05T09:44:10.382Z In(05) vcpu-1 CPU reset: soft (mode Emulation)