fusion11.5 installed windows7, installed the VMware Tools , at the Security&Privacy==>Privacy==>Accessibility Fusion's been into the list.
The touchpad or mouse can slide, but clicks have no effect.
The keyboard works fine, can input
fusion11.5 installed windows7, installed the VMware Tools , at the Security&Privacy==>Privacy==>Accessibility Fusion's been into the list.
The touchpad or mouse can slide, but clicks have no effect.
The keyboard works fine, can input
Hi, thank you very much for the response!
I’ve rolled back to u2. May I ask how to upgrade ESXi670-201911001 from u2?
U2 upgrades to u3 without rebooting, and then apply ESXi670-201911001 directly, after which rebooting is performed? If this process is not correct, could you please give some clue to upgrade u2 to ESXi670-201911001 u3?
Thanks!
I am trying to create a vm for an OS; however, I keep getting the following errors.
"
Feature 'cpuid.ds' was absent, but must be present.
Feature 'cpuid.ss' was absent, but must be present.
Feature 'cpuid.intel' was absent, but must be present.
Module 'FeatureCompatLate' power on failed.
Failed to start the virtual machine."
What am I doing wrong?
I have a cluter including a few hosts(version Esxi 6.5) .
In one host of cluter ,I have found that messages "sfcb-vmware_raw{XXXXX]" show in /var/log/syslog.log repeatly. Also ,files such as localcli-zdump.000,sfcb_vmware_bas-zdump.00X and sfcb_vmware_raw-zdump.00X having been generated under /var/core.
Who knows what happen? Is it a bug?
syslog.log:
/var/core:
Upgrade directly from 6.7u2 to the new patch in one step. Do not upgrade to 6.7u3 and then to the new patch as a second step.
I receive the following error after deploying the recently packaged app (either Project or Visio):
"The application can't start because AppVIsvSubsystems62.dll is missing from your computer"
The answers typically state to reinstall the app, or use the online office repair tool, both of which aren't helpful in our non-persistent environment.
Our base image includes:
OS:
Windows 1809
Base Programs:
AppVols Agent 2.18
Office Pro Plus 2016
C++ Redist 2013, and 2017 (both x86, and x64)
VMware Tools 10.3.5
Visio and Project work in the packaging environment, but break once provisioned to test users.
Installing Visio and Project in the user session works as intended, but non persistent environment makes this redundant exception of testing.
We thought it may be AV causing the issues, but cant confirm yet.
Evening Everyone,
So I updated my Horizon View environment this past weekend. (Connection, Composer, Security Servers, and View Agent on Golden Images) All is working as expected. Oh yeah I updated from a 7.3 build. There is one issue that is a bit annoying. So when a user locks their guest operating system session (Windows 7) and come back to login after 10 minutes or so, they login successfully however after a couple of seconds, the VDI desktop resolution changes to 1024 x 768. This is not the resolution of the monitors, SO they have to disconnect that session and log back in to fix the issue. This was not happening on 7.3. Any assistance would be greatly appreciated.
Thin Clients - WYSE 7020
Guest OS - Windows 7
Horizon Agent - 7.10
Connection Server - 7.10
Security Server - 7.10
Composer Server - 7.10
Hi All,
I would like to gather information on which is the best way to migrate vCenter Windows 5.5 to VCSA 6.5.
Our challenge is that the setup is using dvswitch 5.5.
And I saw a KB that migrating dvswitch from a new version may result downtime that,s why we are trying to minimize or much better eliminate that concern especially this is production environment.
Upgrade a vSphere Distributed Switch to a Later Version
Will using vCenter migration tool automatically upgrades the dvswitch version from 5.5 to 6.5?
Issue looks similar to: VMware Knowledge Base
Can you also check if SEL logs are full? If so, please try clearing them.
Since the host is marked as not responding, let's first focus on that.
Check the vmkernel.log file for the affected host and search for "hostd detected to be non-responsive" entry. If present, the hostd process is hung and a host restart is something worth trying.
A strong indicator that the hostd is hung after being marked as Not Responding, is if you run the esxcli command and it hangs however localcli works at the same time.
Olá,
Meu nome é Lucas.
Instalei o Android x86 (android-x86_64-8.1-r3 ) como uma máquina virtual e funcionou normalmente. Em uma ocasião o VMware não conseguiu restaurar uma máquina em modo de suspensão e fiquei vários dias preso nisso até encontrar um tutorial (VMware Knowledge Base ) . Consegui iniciar a máquina uma única vez e depois disso ao tentar iniciar fica preso no logo do Android.
Image may be NSFW.
Clik here to view.
Essa são as configurações da máquina:
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
O 3D está ativado.
Image may be NSFW.
Clik here to view.
Pasta:
Image may be NSFW.
Clik here to view.
Já tentei usar nomodeset xforcevesa, mas não adiantou. A inicialização não produz nenhum código de erro em pop-up ou semelhante.
Meu sistema:
Image may be NSFW.
Clik here to view.
Estou usando a versão do VMware® Workstation 15 Player, 15.5.0 build-14665864.
Thanks, I'll keep my eye out for 8.0.1. I had tested uploading a zip with the dependencies, but it's obviously not ideal, but OK for short term.
I'm following up the issue with the Cloud Accounts with the team that looks after the proxy. Seems like the HTTP CONNECT tunnels are being blocked, so I'm guessing it connects differently to vRA 7.
VCDB=# SELECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
VCDB-# FROM pg_class C
VCDB-# LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
VCDB-# WHERE nspname NOT IN ('pg_catalog', 'information_schema')
VCDB-# AND C.relkind <> 'i'
VCDB-# AND nspname !~ '^pg_toast'
VCDB-# ORDER BY pg_total_relation_size(C.oid) DESC
VCDB-# LIMIT 20;
relation | total_size
---------------------+------------
vc.vpx_event_arg_68 | 253 MB
vc.vpx_event_arg_67 | 253 MB
vc.vpx_event_arg_66 | 250 MB
vc.vpx_event_arg_69 | 249 MB
vc.vpx_event_arg_70 | 246 MB
vc.vpx_event_arg_65 | 246 MB
vc.vpx_event_arg_71 | 246 MB
vc.vpx_event_arg_72 | 245 MB
vc.vpx_event_arg_64 | 241 MB
vc.vpx_event_arg_60 | 240 MB
vc.vpx_event_arg_73 | 240 MB
vc.vpx_event_arg_61 | 239 MB
vc.vpx_event_arg_83 | 239 MB
vc.vpx_event_arg_82 | 237 MB
vc.vpx_event_arg_77 | 237 MB
vc.vpx_event_arg_63 | 236 MB
vc.vpx_event_arg_79 | 236 MB
vc.vpx_event_arg_81 | 236 MB
vc.vpx_event_arg_75 | 235 MB
vc.vpx_event_arg_78 | 235 MB
(20 rows)
The problem is solved.
rm all about VMware's files or folders ,and reboot the OS, and reinstall the fusion.
Hi,
We have 2 vCenters version 6.5 that are in linked mode. The vCenters are in 2 different physical locations. There is 1 external PSC at 1 location that both vCenters are registered with.
We are trying to get clarity on what would be the ideal end solution if upgrading to 6.7? We were thinking first deploying an additional 6.5 external PSC to the physical site without a PSC. Same SSO domain as existing PSC, but a different SSO Site name. Then, first upgrade the 2 PSCs to 6.7. Then upgrade the 2 vCenters to 6.7. Re-configure the vCenter at the physical site with the newly deployed PSC to point at the newly deployed PSC at that same physical site. Converge each external PSC into an embedded PSC with each of their associated vCenters.
However, it seems when looking at vSphere 6.7 supported and deprecated typologies that the final topology described above would not be supported in 6.7?
Any suggestions on the best, supported way to approach this would be appreciated.
Thank you,
Mark
The migration assistant tool would copy all the configuration data including the vDS to the new appliance. However, I would recommend having the config exported prior to the migration attempt. You would need to schedule a downtime for the migration but not separately for vDS.
Hi Mark,
The following guide covers this scenario:
https://docs.vmware.com/en/VMware-vSphere/6.7/vsphere-vcenter-server-671-upgrade-guide.pdf
Depending upon your VM Guest, there are several additional things that affect the resolutions available and the startup resolution.
You have already noted the part that provides the basic capabilities limits (in so far as the svga.xxxxx settings in the .VMX file are concerned). But to quickly cover it again:
svga.autodetect = "FALSE" | This turns off the ability to automatically adjust the SVGA VRAM and resolution and colour bit depth to match the HOST-provided display environment. |
svga.maxWidth = "1024" | This determines the maximum theoretical display width |
svga.maxHeight = "768" | This determines the maximum theoretical display height |
svga.vramSize = "134217728" | Determines the max theoretical VRAM to emulate/allocate (width x height x 4 bytes). Probably only an issue if you have set it too small, or have used more than 16MB in a WorkStation Hardware Version 6 VMX file. This value being too big is not such an issue. WS HWVersion6 default is 16MB, WS HWVersion7 default is 128MB |
svga.spoof16bbpHost="TRUE" | This determines whether the maximum colour depth is 16 bits or 32 bits. You will need this if you are using DirectX on Windows 9X. |
Once you have done this edit to a powered-down VM, you can power up the VM and do some more tweaking - which will depend upon the Guest OS . I will assume here that it is Windows 98 or Windows ME. I know that Windows NT4 has a different registry organization and data format to these, but the concept is essentially similar. You can scrub the existing entries for SVGA driver's resolution and use your own "preferred" resolutions. This will mean that, after a reboot, these will be the resolutions offered (unless restricted by the VMX file or the SVGA driver).
REGEDIT4
; Clear all the pre-existing SVGA modes [-HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\DISPLAY\0000\MODES]
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\DISPLAY\0000\MODES\16\1024,768] @="4:3 XGA High-Colour" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\DISPLAY\0000\MODES\8\1024,768] @="4:3 XGA 256-Colour" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\DISPLAY\0000\MODES\16\800,600] @="4:3 SVGA High-Colour" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\DISPLAY\0000\MODES\8\800,600] @="4:3 SVGA 256-Colour" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\DISPLAY\0000\MODES\16\640,480] @="4:3 VGA High-Colour" [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\DISPLAY\0000\MODES\8\640,480] @="4:3 VGA 256-Colour" |
Finally, you can (if you want) provide for far higher resolutions - both in the VMX and in the REG file - but these will NOT be offered via the OS unless the MONITOR is marked as being capable. To impose that limit, you can create a Monitor.INF file (or similar name like MyLowResMonitor.INF) and install that as your display monitor for the OS. A simple one is shown below. It is ultimately this INF file that determines what the "default" resolution (and maximum) will be that the OS allows. As a result, the VMX edits merely make sure VMware is expecting them and can support them, and the REG file provides options within that range. These are (if you like) establishing the hardware ability of your emulated video card. The INF file, however, actually sets the limit that the OS will attempt based on the display screen, not the card. So enforcing all three of these things is highly recommended. Interestingly, it does mean that if you are using a different monitor, you can just change the INF file, if the "card emulation" is already covering those higher resolutions.
; Custom monitor information file - generated by PowerStrip 3.0, 04/08/2019 ; Copyright (c) 1995-2005, EnTech Taiwan. ; Web: http://www.entechtaiwan.com
[Version] Signature="$CHICAGO$" Class=Monitor ClassGUID={4d36e96e-e325-11ce-bfc1-08002be10318} Provider=%MFG%
[Manufacturer] %MFG%=MonMfg
[MonMfg] %MODEL%=Mon.Install
[Mon.Install] DelReg=DEL_CURRENT_REG AddReg=Mon.AddReg,RES,DPMS
[Mon.AddReg] HKR,%MODE%,Mode1,,%RANGE%
[DEL_CURRENT_REG] HKR,MODES HKR,,MaxResolution HKR,,DPMS
[RES] HKR,,MaxResolution,,%MAXRES%
[DPMS] HKR,,DPMS,,0
[Strings] MFG="VMWare" MODEL="This is my special XGA monitor" MAXRES="1024,768" MODE="MODES\640,480" RANGE="30.0-75.0,50.0-85.0,+,+" |
So does this all work? Well, I used this mechanism to create the display resolution of High-Colour 2560 x 1440 for my Dell U2713HM monitor on a guest Windows ME virtual machine. So I'd say: yes, it works. Even the DirextX 9 diagnostics, even for 3D.
By the way - don't go lower than 640x480 on Windows 9X, as this wasn't really supported. On my Windows ME guest system the display collapsed if I uses 640x400 (Extended EGA) or 640x360 (EGA). Apparently Windows XP was intended to run on at least an SVGA system (800x600), so don't be surprised if trying VGA (640x480) on XP causes issues.
Hi hankers,
Would yo please try to uninstall the VMware Tools and reinstall it in your Windows VM and see if it helps?
If the issue persists, would you please attach the vmware.log to this thread? You can find it by following the steps as below.
1) Click VMware Fusion=>Window=> Virtual Machine Library.
2) Right click the VM you are running with.
3) Press Command button, then choose 'Open latest log file'
4) Click 'Reveal' button on the left top window
Regards,
-Rick
Thanks again Wil! From the information that I was able to find on the internet, the tool is good for both parallel as well as USB. I must say that the driver installer is very odd, because despite selecting to only install the parallel driver, it installs only USB.
In any case, I'm giving up. All the time spent on this is not worth it. It would have been good to nail down the problem though! Thanks for sticking with me through all this time. Cheers!