Hi all,
Running Horizon 7.6 backend and connecting with client 4.8.1
I am starting to see this more and more with my users. They go to run an app and get the following error message:
They close the error message and start the app and everything works fine. Just wondering if there is a solution to this.
TIA
I ran skyline a few months ago before upgrading esxi host, vcenter etc ( 6.0 to 6.5u2) . However it is still showing critical errors which can be resolved by a patch on our previous version.(6.0)
The Skyline appliance was powered off during the upgrade time, and is now running. The collector has been going for a couple of days, and the findings show a recent date.
Ideas?
This compatibility matrix shows GRID K1 only up to Horizon 7.5. But I don't see any reason why Horizon 7.6+ wouldn't be compatible, since ESXi 6.5 supports GRID K1 (with or without Horizon). I have a feeling that VMWare simply stopped updating that compatibility page. Can anyone confirm?
Since I don't see an executable for Windows Photo Viewer in Windows 10 how can I use UEM to make it the default program for certain file types?
Hi,
My ESXI box has been working fine but tonight I gave it a reboot and upon coming back up one of my datastores has vanished , the drive the datastore is on shows as present in the devices. I have included pictures, please can someone help me?
It has been restarted before without issue so not sure why it did this on this reboot.
thank you for your help
Upgraded from 9.1.0.1 to 9.5 on three out of four cell servers. The fourth cell post upgrade errors on service vmware-vcd start with the following errors.
Cell.log
- Bootstrap application: start Fatal exception caught during application bootstrap. Halting application. Message: '/opt/vmware/vcloud-director/etc/global.properties'
Cell-runtime.log
- 2019-01-10 17:05:25,937 | WARN | Bootstrap Application | CommonsConfigurationFactory | Server configuration file not found: /opt/vmware/vcloud-director/etc/global.properties |
org.apache.commons.configuration.ConfigurationException: Unable to load the configuration from the URL file:/opt/vmware/vcloud-director/etc/global.properties
However i can "cat /opt/vmware/vcloud-director/etc/global.properties" and comparing it to other cells seems correct. See output below.
# Database connection settings
database.jdbcUrl = jdbc:jtds:sqlserver://redacted:1433/vcloud;socketTimeout=90
database.username = redacted
database.password = redacted
# Product display name
product.display_name = VMware vCloud Director
# Maximum number blocking tasks (per cell) to be resumed when expired.
# This property is taken into account only when blocking task's default timeout action is "Resume".
# Uncomment this line and set the desired value. Otherwise, the default value (1000) will be used.
# blockingTasks.timeoutResumeRate = 1000
product.version = 9.5.0.11038232
product.build_date = 2018-11-27T21:25:46-0800
vcloud.cell.ip.primary = redacted
consoleproxy.host.https = redacted
vcloud.ssl.password = redacted
vcloud.ssl.key.password = redacted
vcloud.ssl.truststore.password = redacted
consoleproxy.keystore.password = redacted
consoleproxy.keystore.path = /opt/vmware/vcloud-director/etc/proxycertificates
audit.syslog.host =
audit.syslog.port = 514
system.info = aDYYIDRwlRaU1fLfnqgvgTMzp9YgEesQDALS53T73EM=
system.version = 1
vcloud.cell.uuid = redacted
vcloud.cell.ips = redacted
user.keystore.path = /opt/vmware/vcloud-director/bin/../jre/bin/certificates.ks
user.keystore.password redacted
I would like to disassociate a datastore cluster from a host. I have already unmounted all datastores and devices but when i look at the datastore cluster it still shows the host as connected.
Will this go away when the storage is unzoned? Or is there a way to tell the DS cluster to forget about the host? I cannot find anything that helps.
Thank You
I have been fighting this for quite some time. When I run "connect-viserver servername" it will prompt me for the logon credentials in our Windows 2016 jump box, but it works just fine in our older 2008 jump boxes. PowerCLI is the latest version on both, so is our VCSA 6.5, external PSC. Both the VCSA and PSC are joined to the domain.
I have boiled this down to an encryption problem. Due to DOD STIG (security) requirements, the registry key HKLM/software/microsoft/windows/currentversion/policies/system/kerberos/parameters/SupportedEncryptionTypes is different in Windows 2016. in 2016 it is 7ffffff8, in 2008 it is 7ffffffc. Changing this value fixes the problem. This bit change controls RC4-HMAC. In other words, we have to enable RC4-HMAC to allow PowerCLI to properly pass thru the credentials. This is not acceptible on soooo many levels.
How do we get PowerCLI to properly passthru credentials without enabling RC4-HMAC?
Having clean installed ESXi 6.7,.0 i can no longer install OS from ISO image, or local/attached physical drives..
I can only upload to Datastore, ad install from there.... Is the client plugin available to download separately ? as i don't have vCenter. or this is part of virtual applicance ?.. I do have this, just not installed yet... On login screen there is no link at the bottom, and no link after either.
Hi,
I need to move the VCSA from one host to another. Local storage is used to host the VCSA. I'm using v6.7u1. I found this KB:
This part of the KB seems to fit what I need to do:
To move vCenter Server between hosts when storage is not shared, perform one of these options:
Note: These options require the MAC of the virtual machine to be manually set. For more information, see Setting a static MAC address for a virtual NIC (219).
Has anyone tried either of these? Any issues if so? Both seem straightforward.
Are there any other options I should try instead?
Thanks, and any advice is appreciated!
I am running SCO OS6 and Linux Mint 18 on VMWare 15.02 on Windows 10. The problem is that VMWare randomly drops network connectivity. The only way to fix it is by rebooting SCO or Mint. Sometimes it runs for days without problems, sometimes we have to reboot at least 5 times a day and it becomes annoying. No, it is not Windows as we can connect to other computers on the network when VMWare connectivity is down. SCO or MINT continue to work and localhost works fine.
Hi,
I run "esxcli network nic stats get -n vmnic5" on esxi 5.5 and get following output:
NIC statistics for vmnic5
Packets received: 1606842548
Packets sent: 1293834
Bytes received: 102837923342
Bytes sent: 82805663
Receive packets dropped: 0
Transmit packets dropped: 0
Total receive errors: 3023708
Receive length errors: 0
Receive over errors: 3023708
Receive CRC errors: 0
Receive frame errors: 0
Receive FIFO errors: 0
Receive missed errors: 4622596
Total transmit errors: 0
Transmit aborted errors: 0
Transmit carrier errors: 0
Transmit FIFO errors: 0
Transmit heartbeat errors: 0
Transmit window errors: 0
Can someone please explain me as to what Receive over errors mean. Is there any link of document to explain each of these errors.
-Thanks
I have a few just restored VM's, I can see them by CLI: get-vm xyz.
However, I could not see xyz VM from vSphere GUI.
Could you please advise on what the cause could be, and what should I do?
Thanks,
I’ve been trying to get a VDI up and running on one of my workstations running Linux Mint 18.3. It’s a bit frustrating because I have one successful installation with this combination, but not on the workstation I want it to be on.
My employer provides a Windows 7 VDI that I use for Outlook mail and Communicator and other Windows-centric things that I need for work. I’ve been using the Horizon clients on my Linux Mint installs for years with no problems. Last year I had Horizon Client 4.8 running on Linux Mint 18.0, which was fine until we started working with another company that had Published Applications that required Horizon Client 4.9. Naturally, this broke the VDI that I needed for work. It would get as far as bringing up the window that would enclose the Windows desktop but then the window disappears silently. The published applications run just fine on my workstation – it’s just the VDI that fails.
I thought that maybe if I upgraded my Mint installation, that might help, so as a test I upgraded my laptop to Mint 18.3, which is based off of Ubuntu 16.04.5. Success! I am able to bring up my work VDI in Horizon Client 4.9.0 in Mint 18.3 on my laptop. So, full of hope I went to my workstation and upgraded to Mint 18.3, installed Horizon Client 4.9.0, selected my VDI and got the same failure I had before. I’ve since upgraded the Horizon Client on my workstation to 4.10.0, but still no love.
The only difference in the vmware-horizon-client log between my laptop and workstation is that the workstation shows:
2019-01-11 14:50:27.277-05:00: vmware-view 7866| cdk_pcoip_desktop_present_changed: rmks present is FALSE.
2019-01-11 14:50:27.277-05:00: vmware-view 7866| cdk_pcoip_desktop_state_changed: RemoteMKS connection failed.
The log in the laptop shows:
2019-01-11 10:17:16.111-05:00: vmware-view 2931| cdk_pcoip_desktop_should_fit_again: Screen width 3200, height 1800, mks width 2400 height 1350.
2019-01-11 10:17:16.111-05:00: vmware-view 2931| cdk_pcoip_desktop_MKS_size_changed: new MKS size is (2400 x 1350).
2019-01-11 10:17:16.111-05:00: vmware-view 2931| cdk_pcoip_desktop_MKS_size_changed: Screen change done, so update workarea.
2019-01-11 10:17:16.111-05:00: vmware-view 2931| cdk_pcoip_desktop_update_workarea :Not in Unity mode, so not sending work area sync request.
My laptop has Intel-based CPU and GPU, while my workstation has AMD-based CPU and GPU. That’s the only thing I can think that is causing the issue. I have a HiDPI display on my laptop and it’s a pain to use Windows on there because I have to use the accessibility features of Mint to magnify the Windows desktop so I can read things. I want to get Windows back on my Workstation, but I don’t know if there’s a way.
Is there a way to create a vRealize report that would show the Datastore Name, LUN Naa identifier and extent LUN Naa Identifier.
For example, If a datastore "LUN1" of 500GB is created by 2 LUNs of 250GB each. I would like to get a report as below:
Datastore Name Size LUN identifier
LUN1 500GB naa.5672bcb0123456771974541b0c12345, naa.5672bcb012345677197345550c12345
Is this possible?
Hi all,
I have shut down one vCenter and one external PSC temporarily to relocate the equipment, however the login for the online PSC is incredibly slow because it keeps attempting to authenticate to the other PSC.
Is there a way to prevent it from trying to login to the other controller while it is down?
Thanks!
Is there anyway to disable a virtual NIC connected to a VM through the CLI? I have looked through the commands and I can only find disconnecting a vmnic on the host but not a NIC on the VM. Thank you!
I wish to increase a VM disk size. Is this possible in the 6.7 web client?
I have searched but been unable to find how to do this.
Thanks in advance.
Hi
I was attempting to clone a vmdk using vmksftools -i and it failed. The problem I am running into now is the VM wants me to answer a question
You do not have write access to a partition ....
Allow
Allow All
Deny
Deny All
I want to back out of this operation. When I select Deny, it asks another question
Selecting Deny or Deny All will return a fatal disk error to the boot program. Do you want to continue?
I select Yes because this is only a test VM and I would like to delete it.
However after answering the question, it starts back over and I have to answer the question again. It seems to never stick. I can't get out of the loop to delete the VM. What are my options?
When PXE installing ESXi 6 on BIOS clients it seems the TFTP requests are not correctly handled.
kernel_bios = /NWA_PXE/$HEAD_DIR$/mboot.c32
append_bios = -c /NWA_PXE/$HEAD_DIR$/BOOT.CFG
ipappend_bios = 2
For every needed file a TFTP client usually perform a "Read Request" asking for the size of the file (tsize) answered by the
server with an "Option Acknowledgment" returning "tsize=xxxx", then the client "Aborts" the transfer and checks that the returned
file size is OK, then the client performs a second "Read Request" this time really transferring the requested file.
On BIOS targets the VMware provided mboot.c32is the TFTP client in charge of transferring the components listed at BOOT.CFG.
mboot.c32 BOOT.CFG but it "forgets to Abort" those request; next it requests
those 151 files "again" this time for really retrieving them.
This presents several problems with TFTP servers (i.e. Serva ) that control the number of orphan TFTP transfers in order to prevent
resource abusive TFTP clients.
On the other hand installing ESXi 6 on UEFI targets presents the classic TFTP initial sequence not leaving behind orphan transfers.
"Read Request"->
<- "Option Acknowledgment"
"Abort" ->
In this case it is VMware BOOTX64.efi (not mboot.c32) the one in charge of the client side of the TFTP transfers.
kernel_efi64 = /NWA_PXE/$HEAD_DIR$/EFI/BOOT/BOOTX64.efi
append_efi64 = -c /NWA_PXE/$HEAD_DIR$/BOOT.CFG
ipappend_efi64 = 2
See the attached Wireshark traffic capture
Best,
Patrick
