Are you the publisher? Claim or contact us about this channel

Embed this content in your HTML


Report adult content:

click to rate:

Account: (login)

More Channels

Channel Catalog

Channel Description:

Most recent forum messages

older | 1 | .... | 897 | 898 | (Page 899) | 900 | 901 | .... | 904 | newer

    0 0

    No, we are not using app volumes.

    0 0

    We are trying to run Horizon Chrome OS Client (Client4.9 on Horizon 7.5) and We can't seem to run the app in Full Screen. The user sees the Chrome Top Navigation menu as well as the Windows Menu below it. If the user hits the wrong "X" the machine restarts because of Kisok Mode. Other than this it works really well.




    Also wondering where you upload the JSON file to configure the broker. We are using GSuite and the documentation is a little lacking in guidance.



    0 0

    I still have issues on macos 10.4 mojave with 4.9 client. Not always, but in 50% of times.

    0 0

    I should probably also add that if I log into a VM from the pool with the same account, only the first login takes forever, subsequent logins are around the 5 second mark.  If this was a persistent pool I would be happy but it's a floating linked clone.

    0 0

    I am unable to list or move unused replicas. Everything looks good in the View Administrator. System health is green from top to bottom. All pools functioning normally (linked clones).


    Here's the issue: I am unable to list (replica.txt) or move replicas to the UnusedViewComposerReplicaFolder

    Sviconfig runs fine until it tries to "Load replica info from database" Here is the output I'm getting:


    Establishing database connection.

    Database connection established successfully.

    Exploring replica.

    Load data from SVI_VC_CONFIG_ENTRY table.

    Load replica info from database.

    SviConfig finished with an error. Exit code: 4

    Invalid certificate.


    If anyone can help with this issue it would be much appreciated.

    0 0

    Did you do anything to the default profile, if not you may want to look at


    Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop | VMware


    there is a section in there about using the vmware optimization tool and how to configure it to modify the default profile. Usually if the first logon is a lot longer then the other login attempts, its doing a lot of work. They suggest using mandatory profiles at the end, which can be quicker, but just having the optimizer tool run its optmiizations on the default profile helps.

    0 0

    OS Optimization Tool has already been run so unfortunately, that won't help in this case...

    0 0

    If you recently changed the Cluster name, Just rename it back to the old name.

    0 0

    I have the exact same problem, first had a lot of trouble getting past some python error. Then got the Horizon client .. hurray, but still no luck when i access my companies workspace to get into my VDI. Firefox does not know where to find the software.


    Have you found a solution?




    0 0

    The VMware Horizon Client for Linux version 4.9.0 fails to start with the following error on my machine:

    $ vmware-view /usr/lib/vmware/view/bin/vmware-view-crtbora: symbol lookup error: /usr/lib/vmware/ undefined symbol: _ZN4Glib7ustring5beginEv

    The missing symbol is:

    $ echo "_ZN4Glib7ustring5beginEv" | c++filt  Glib::ustring::begin()

    My machine is running Fedora 28 and the glibmm library does provide the Glib::ustring::begin() symbol, but only through C++11 ABI:

    $ objdump -T /usr/lib64/|grep _ZN4Glib7ustring.begin | awk '{ print $NF; }' | c++filt Glib::ustring::begin[abi:cxx11]()

    Is there any chance of getting this fixed in a newer version of the Horizon Client by providing a build for a recent Fedora release?

    0 0

    You would have to get them to support it first


    • The OpenSSL library is updated to version openssl-1.0.2o. For your convenience, the Horizon Client installer provided on the VMware Downloads site downloads and installs the library.
    • Horizon Client for Linux 4.9 has been tested and is supported on the following 32-bit operating systems if you use the installer provided by VMware:
      • Ubuntu 16.04
      • Red Hat Enterprise Linux (RHEL) 6.10
    • Horizon Client for Linux 4.9 has been tested and is supported on the following 64-bit operating systems if you use the installer provided by VMware:
      • Ubuntu x64 16.04 and 18.04
      • Red Hat Enterprise Linux (RHEL) 6.10 and 7.5

    0 0

    We have vmware horizon 7.3.2 and windows 10 64 bit linked clones.. dedicated assignment


    The problem is that the vdi would disconnect all of a sudden and afterwards

    1.the vdi might have restarted

    2.on connecting again the screen size is around 3/4 and the rest is of black screen..need to restart the vdi to get this fixed.

    This issue does not happen with any sequenses.completely random and atleast on alternate days one or other user face this issue.


    Also for the first case as mentioned above i have found mini dump file in the vdi...

    Analyisng that shows ntoskrnl.exe for couple of users...

    In the vdm logs under logs.txt could see some errors saying writing crash dump to wsnm*.dmp

    How to read this dmp..any clue about the issue would be really helpful for me to have a peaceful night sleep!!!!

    0 0

    Is there a way to interpret the logs.txt under vdm logs like I am looking for the step by step process which happens when a user logs in and for some reason if the desktop is disconnected , how to analyse in the logs file..

    What is the scops of this log s.txt. what and all the issues will be reported here?


    For a normal vdi connection what and all the logs entries will be present??

    Atleast are there any links or books where i could find these information...??


    0 0

    Hello all people!

    Already found a similar problem here on the forum. The question is not so fresh, but my answer may help. I also encountered a problem in working with a virtual desk, I had a problem, either one or the second device was working.

    I found the USB Network Gate, I managed to solve the problem. It's good that in the trial version you can understand whether the software is suitable or not.

    0 0

    Saying they support RHEL 7.5 is actually an overstatement. The client comes with a bunch of bundled libraries that are of different versions than the ones shipped with any of the distributions, including Fedora. It also uses dirty hacks to work with some system libraries with different SONAME, like libudev or libffi. Personally, I'm not installing all the bundled stuff that's in Fedora already and up to and including 4.8.0 it has been working on Fedora 27 and 28 beautifully without any issues. You can see my repackaging here. With 4.9.0, even if I do include all the bundled libraries, they are still overridden by system libraries, so it still fails to start, though in a different place.


    In my opinion, it would be best to build proper binary packages linked with libraries available on each supported distribution. I can help if VMware is listening. Of course, all this would be moot if only the client sources were released under an open license.

    0 0

    The Debugging Tools for Windows (WinDbg) are what we have used in advance to look at dump files. The challenge is that you may not have the proprietary symbol files that VMware uses so debugging could be limited and would require opening an SR so VMware can look at them.


    It sounds like something is crashing in the guest which could be the VMware processes or something interacting with them (Anti-Virus, etc...). I would first test with a vanilla image, one with Anti-Virus and one without to to see if the issue still occurs. Then slowly add your applications to the images until you can reproduce the issue. You could also open a case with VMware but from my experience they will ask you to do exactly what I just suggested.


    Are you planning an upgrade anytime soon? There have been a number of important fixes in 7.4.x, 7.5.x and 7.6.0.

    0 0

    I apologize, my problem was in the golden image.

    0 0

    I get what your trying saying, but I think they only test the client on Ubuntu and Red hat, fedora and centos while similar are packaged different as you know. Trying to support every Linux distro is tough, which is why they stick with red-hat and Ubuntu as they are the most used commercially.. The same thing is true with the virtual desktops, they seem to only support Ubuntu and red hat, with the best support for red-hat.


    Maybe someone else has seen this and has a suggestion, but I don't think you'll get to far with vmware themselves, you'll get the standard its not supported response

    0 0

    The vmware-view-crtbora binary is very odd in 4.9.0. It seems to have STABS debug information:

    $ objdump -h vmware-view-crtbora |egrep '.stab|debug'
    29 .stab         0022044c  0000000000000000  0000000000000000  00301430  2**2
    30 .stabstr      006dfa75  0000000000000000  0000000000000000  0052187c  2**0
    32 .debug_aranges 000001c0  0000000000000000  0000000000000000  00c01360  2**4
    33 .debug_pubnames 0000007c  0000000000000000  0000000000000000  00c01520  2**0
    34 .debug_info   0000ec5f  0000000000000000  0000000000000000  00c0159c  2**0
    35 .debug_abbrev 00001709  0000000000000000  0000000000000000  00c101fb  2**0
    36 .debug_line   00002645  0000000000000000  0000000000000000  00c11904  2**0
    37 .debug_frame  00000088  0000000000000000  0000000000000000  00c13f50  2**3
    38 .debug_str    000028ac  0000000000000000  0000000000000000  00c13fd8  2**0
    39 .debug_loc    0000d052  0000000000000000  0000000000000000  00c16884  2**0
    40 .debug_ranges 00000ad0  0000000000000000  0000000000000000  00c238d6  2**0

    while the one in 4.8.0 has GNU debug information:

    $ objdump -h vmware-view-crtbora |egrep '.stab|debug'
    26 .gnu_debuglink 00000038  0000000000000000  0000000000000000  002fc2e8  2**2
    27 .gnu_debugdata 00010d78  0000000000000000  0000000000000000  002fc320  2**0

    I'm not sure it's relevant to the issue or not.

    Anyway, after patching the /usr/bin/vmware-view wrapper script to run vmware-view-crtbora only when it's actually installed instead everywhere except on ARM:

    --- vmware-horizon-client-    2018-10-18 10:11:34.082958109 +0200
    +++ vmware-horizon-client-    2018-10-18 10:34:22.654390678 +0200
    @@ -23,7 +23,7 @@ else

    -if [[ $ROLLBACK_VMWAREVIEW = "" ]] && [ $cpu -eq 0 ]; then
    +if [[ $ROLLBACK_VMWAREVIEW = "" ]] && [ $cpu -eq 0 ] && [ -x "$binPath/bin/vmware-view-crtbora" ]; then

    the 4.9.0 client works without the Seamless Window Feature but otherwise fine on Fedora 28 using system libraries where available.

    0 0

    We are facing the same issue.. The users are unable to reconnect to their disconnected session.


    OS: WIndows 10 LTSB


    App Volume : 2.14

    VMware Tools  10.2.5


    I checked the below KB. that didn't help.

    VMware Knowledge Base


    Any workaround or fix for this issue. Appreciate your help

older | 1 | .... | 897 | 898 | (Page 899) | 900 | 901 | .... | 904 | newer