andreir Tracker

Connect-NsxtServer is very slow

andreir — Wed, 05 Aug 2020 21:52:52 GMT

Hi all,

having an issue with Connect-NsxtServer cmdlet - it takes almost 2 minutes to connect to the NSX-T manager. Is that normal? If not, any ideas on how to troubleshoot?

PS C:\> Measure-Command { Connect-NsxtServer $server }

Days : 0

Hours : 0

Minutes : 1

Seconds : 53

Milliseconds : 815

Ticks : 1138153958

TotalDays : 0.00131730782175926

TotalHours : 0.0316153877222222

TotalMinutes : 1.89692326333333

TotalSeconds : 113.8153958

TotalMilliseconds : 113815.3958

Unable to remove imported network

andreir — Wed, 05 Aug 2020 21:19:04 GMT

Hello all,

Cloud Director 10.1.1, trying to remove the imported network in this Org vCD, the last network that needs to be removed before I can delete the Org, however I get the following error:

Error: [ acca0af6-3af5-4503-9341-b7e4037fa1df ] Entity external-dhcp-1 cannot be deleted, because it is in use.

Nothing is connected to this network, in fact this segment is already removed from NSX-T manager along with the T1 gateway it was connected to.

Any clues on how to get rid of this network? Thanks in advance!

Re: After the deployment of nsx-t 3.0 finish and start the vm, some service is not started and cannot be accessed

andreir — Fri, 22 May 2020 14:26:03 GMT

NSX-T 2.5.1 has the same issue. Log spam about not being able to connect to some local services.

<180>1 2020-05-22T14:20:50.537Z nsx-manager-3 NSX 3695 - [nsx@6876 comp="nsx-manager s2comp="nsx-rpc" tid="3716" level="WARN"] RpcConnection[15873 Connecting to tcp://127.0.0.1:4096] Couldn't connect to tcp://127.0.0.1:4096 (error: 111-Connection refused)

<180>1 2020-05-22T14:20:50.538Z nsx-manager-3 NSX 3695 - [nsx@6876 comp="nsx-manager s2comp="nsx-rpc" tid="3716" level="WARN"] RpcTransport[2] Unable to connect to tcp://127.0.0.1:4096: 111-Connection refused

<180>1 2020-05-22T14:20:50.675Z nsx-manager-3 NSX 1830 - [nsx@6876 comp="nsx-manager" subcomp="opsagent" s2comp="nsx-net" tid="1857" level="WARN"] StreamConnection[15887 Connecting to unix:///var/run/vmware/nsx-proxy/aphinfoservice.sock sid:15887] Couldn't connect to 'unix:///var/run/vmware/nsx-proxy/aphinfoservice.sock' (error: 2-No such file or directory)

Re: New-ContentLibraryItem OVA import fails with "certificate is not trusted"

andreir — Thu, 21 May 2020 22:55:50 GMT

Just in case someone else hits this - until the cmdlet option is added, a solution is to unzip the ova, remove the .cert file, and import it as ovf.

Re: New-ContentLibraryItem OVA import fails with "certificate is not trusted"

andreir — Thu, 21 May 2020 19:08:54 GMT

Hi Luc,

just tried it with the Web Client and it looks like you're right - the problem is with the self-signed certificate bundled with the OVA. This is an official NSX-T OVA that I downloaded from VMware. If I click "Proceed Anyway" then it's imported successfully.

It looks like there is no functionality to ignore OVA certificate with "New-ContentLibraryItem"? Perhaps this can be added in the future?

Thank you!

New-ContentLibraryItem OVA import fails with "certificate is not trusted"

andreir — Thu, 21 May 2020 18:31:52 GMT

Hi all,

using VMware.PowerCLI Core 12.0.0.15947286 on Linux VM. Trying to import an item into vCenter content librarywhich fails with "The certificate is self-signed. The certificate is not trusted..". The certificate check is set to "Ignore" in PowerCLI configuration.

I don't see any options in New-ContentLibraryItem cmdlet to allow untrusted cert. How can I get the OVA imported when vCenter cert is self-signed? Thanks!

PS /home/user> $localContentLibrary = Get-ContentLibrary -Name 'Local library'

PS /home/user> New-ContentLibraryItem -ContentLibrary $localContentLibrary -Name 'nsx-unified-appliance-2.5.1.0.0.15314292' -Files "./tmp/nsx-unified-appliance-2.5.1.0.0.15314292.ova"

An error occurred while trying to update content library item's files. For more details check the inner exception.

vCenter error:

The import of library item 48d9ec5f-5fae-4905-adb1-2bbfa2d5aee1 has failed. Reason: The certificate is self-signed. The certificate is not trusted..

PS /home/user/tmp> Get-PowerCLIConfiguration | select InvalidCertificateAction

InvalidCertificateAction

------------------------

Ignore

Re: NSX-T 2.5.1 - no geneve tunnels

andreir — Tue, 19 May 2020 14:29:42 GMT

This is great, thank you very much! I can confirm that disabling the checksum offload fixes the issue.

Re: NSX-T 2.5.1 - no geneve tunnels

andreir — Thu, 14 May 2020 20:18:49 GMT

Unfortunately we were not successful in resolving this issue. The original problem was observed on Cisco UCS B200 M2 blades running 2.2(8i) firmware and M81KR CNA with 2.2(3b). Since those are no longer supported on ESXi 6.7, we gave up. Best guess is that the VIC driver somehow mangles the encapsulated packet.

Re: NSX-T 2.5.1 - no geneve tunnels

andreir — Wed, 11 Mar 2020 01:54:48 GMT

Reboot did not help, unfortunately.

I also did a packet capture while doing traceflow, and it looks like ICMP packet is received by the destination host:

on source (nsx02 host):

[root@NSX02:~] nsxcli -c start capture interface vmnic5 direction output expression dstip 10.12.0.151

01:30:24.292172 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 116: 10.12.0.152.54710 > 10.12.0.151.6081: Geneve, Flags [O], vni 0x0, proto TEB (0x6558): 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 66: 10.12.0.152.49152 > 10.12.0.151.3784: BFDv1, Control, State Down, Flags: [Poll], length: 24

01:30:25.292190 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 116: 10.12.0.152.54710 > 10.12.0.151.6081: Geneve, Flags [O], vni 0x0, proto TEB (0x6558): 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 66: 10.12.0.152.49152 > 10.12.0.151.3784: BFDv1, Control, State Down, Flags: [Poll], length: 24

01:30:25.606948 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 186: 10.12.0.152.49168 > 10.12.0.151.6081: Geneve, Flags [C], vni 0x11801, proto TEB (0x6558), options [8 bytes]: 00:50:56:b7:85:57 > 00:50:56:b7:c8:2e, ethertype IPv4 (0x0800), length 128: 10.12.67.172 > 10.12.67.10: ICMP echo request, id 0, seq 0, length 94

01:30:26.192260 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 116: 10.12.0.152.54710 > 10.12.0.151.6081: Geneve, Flags [O], vni 0x0, proto TEB (0x6558): 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 66: 10.12.0.152.49152 > 10.12.0.151.3784: BFDv1, Control, State Down, Flags: [Poll], length: 24

01:30:27.092236 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 116: 10.12.0.152.54710 > 10.12.0.151.6081: Geneve, Flags [O], vni 0x0, proto TEB (0x6558): 00:50:5

on destination (esx03 host):

[root@NSX03:~] nsxcli -c start capture interface vmnic5 direction input expression srcip 10.12.0.152

01:30:24.278450 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 116: 10.12.0.152.54710 > 10.12.0.151.6081: Geneve, Flags [O], vni 0x0, proto TEB (0x6558): 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 66: 10.12.0.152.49152 > 10.12.0.151.3784: BFDv1, Control, State Down, Flags: [Poll], length: 24

01:30:25.278480 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 116: 10.12.0.152.54710 > 10.12.0.151.6081: Geneve, Flags [O], vni 0x0, proto TEB (0x6558): 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 66: 10.12.0.152.49152 > 10.12.0.151.3784: BFDv1, Control, State Down, Flags: [Poll], length: 24

01:30:25.593242 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 186: 10.12.0.152.49168 > 10.12.0.151.6081: Geneve, Flags [C], vni 0x11801, proto TEB (0x6558), options [8 bytes]: 00:50:56:b7:85:57 > 00:50:56:b7:c8:2e, ethertype IPv4 (0x0800), length 128: 10.12.67.172 > 10.12.67.10: ICMP echo request, id 0, seq 0, length 94

01:30:26.178576 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 116: 10.12.0.152.54710 > 10.12.0.151.6081: Geneve, Flags [O], vni 0x0, proto TEB (0x6558): 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 66: 10.12.0.152.49152 > 10.12.0.151.3784: BFDv1, Control, State Down, Flags: [Poll], length: 24

01:30:27.078539 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 116: 10.12.0.152.54710 > 10.12.0.151.6081: Geneve, Flags [O], vni 0x0, proto TEB (0x6558): 00:50:56:63:b0:56 > 00:50:56:67:31:cb, ethertype IPv4 (0x0800), length 66: 10.12.0.152.49152 > 10.12.0.151.3784: BFDv1, Control, State Down, Flags: [Poll], length: 24

But the traceflow does not show that it was delivered on the other side?

I'll be happy to provide full packet captures if that might help...

Re: NSX-T 2.5.1 - no geneve tunnels

andreir — Wed, 11 Mar 2020 00:50:38 GMT

These are physical UCS blades, fresh install as far as I know so nothing should've happened on the hosts. The NSX-T never worked correctly after it was set up. Will try to reboot.

Re: NSX-T 2.5.1 - no geneve tunnels

andreir — Wed, 11 Mar 2020 00:18:24 GMT

Zooming in:

NSX-T 2.5.1 - no geneve tunnels

andreir — Tue, 10 Mar 2020 23:15:28 GMT

Hi all,

hitting a really puzzling issue: configured the latest NSX-T on Cisco UCS, created T0, overlay TZ, created a segment and added two VMs. VMs are able to ping the gateway on T0, can ping each other if on the same host, but cannot ping each other if on different hosts. Upon closer inspection, it appears that no tunnels are formed between the ESXi nodes.

I'm able to ping between TEPs with large MTU, so no networking issues as far as I can see, but the tunnels are not formed... BFD shows tunnels are down (please see the output on the bottom).

Not seeing any related error messages in /var/log/vmkernel or /var/log/nsx-syslog.log on the hosts.

Anything else I can check? Would be happy to provide any other output. Please help!!!

Tested VXLAN connectivity and it looks good:

[root@NSX02:~] ping ++netstack=vxlan 10.12.0.151 -s 1600 -d

PING 10.12.0.151 (10.12.0.151): 1600 data bytes

1608 bytes from 10.12.0.151: icmp_seq=0 ttl=64 time=0.271 ms

Checked the logical switches on the hosts and they look good (the switch I'm using is called "test"):

NSX-Manager> get logical-switch

VNI UUID Name Type

71688 5cce3073-c5c9-4cf6-9cad-8db50dd06b68 OV-WEB DEFAULT

71689 8208b2cd-7d0c-407e-aacf-ee9297ef5cf2 OV-DB DEFAULT

71691 fedd3ec3-d3e4-4d02-ac4f-cd94bde02fdf transit-bp-2a5f80db-676d-41f4-b305-1e8591266f94 TRANSIT

71692 c9b96c71-ebff-4572-88a9-7639d2923743 transit-bp-8871e348-42da-447f-9193-70781b09730f TRANSIT

71690 50db354a-bf9c-483f-9637-c397e78d05b7 transit-rl-8871e348-42da-447f-9193-70781b09730f TRANSIT

71681 97655bd6-dd20-4746-8138-656a0c06e9b0 test DEFAULT

71687 6fa865f8-4bb6-439a-a428-a94e27e02090 OV-APP DEFAULT

[root@NSX02:~] nsxcli -c get logical-switch 71681 vtep-table

Logical Switch VTEP Table

-----------------------------------------------------------------------------------------------

Host Kernel Entry

===============================================================================================

Label VTEP IP Segment ID Is MTEP VTEP MAC BFD count

124941 10.12.0.151 10.12.0.128 False 00:50:56:67:31:cb 0

LCP Remote Entry

===============================================================================================

Label VTEP IP Segment ID VTEP MAC DEVICE NAME

124941 10.12.0.151 10.12.0.128 00:50:56:67:31:cb None

LCP Local Entry

===============================================================================================

Label VTEP IP Segment ID VTEP MAC DEVICE NAME

124942 10.12.0.152 10.12.0.128 00:50:56:63:b0:56 None

[root@NSX03:~] nsxcli -c get logical-switch 71681 vtep-table

Logical Switch VTEP Table

-----------------------------------------------------------------------------------------------

Host Kernel Entry

===============================================================================================

Label VTEP IP Segment ID Is MTEP VTEP MAC BFD count

124942 10.12.0.152 10.12.0.128 False 00:50:56:63:b0:56 0

LCP Remote Entry

===============================================================================================

Label VTEP IP Segment ID VTEP MAC DEVICE NAME

124942 10.12.0.152 10.12.0.128 00:50:56:63:b0:56 None

LCP Local Entry

===============================================================================================

Label VTEP IP Segment ID VTEP MAC DEVICE NAME

124941 10.12.0.151 10.12.0.128 00:50:56:67:31:cb None

Checked BFD sessions, tunnels down, no diagnostic....

[root@NSX03:/var/log] net-vdl2 -M bfd -s nvds

BFD count: 3

===========================

Local IP: 10.12.0.151, Remote IP: 10.12.0.153, Local State: down, Remote State: down, Local Diag: No Diagnostic, Remote Diag: No Diagnostic, minRx: 1000, isDisabled: 0, l2SpanCount: 1, l3SpanCount: 1

Roundtrip Latency: NOT READY

VNI List: 71687

Routing Domain List: 8871e348-42da-447f-9193-70781b09730f

Local IP: 10.12.0.151, Remote IP: 10.12.0.200, Local State: down, Remote State: down, Local Diag: No Diagnostic, Remote Diag: No Diagnostic, minRx: 1000, isDisabled: 0, l2SpanCount: 3, l3SpanCount: 2

Roundtrip Latency: NOT READY

VNI List: 71690 71691 71692

Routing Domain List: 2a5f80db-676d-41f4-b305-1e8591266f94 8871e348-42da-447f-9193-70781b09730f

Local IP: 10.12.0.151, Remote IP: 10.12.0.152, Local State: down, Remote State: down, Local Diag: No Diagnostic, Remote Diag: No Diagnostic, minRx: 1000, isDisabled: 0, l2SpanCount: 2, l3SpanCount: 2

Roundtrip Latency: NOT READY

VNI List: 71681 71688

Routing Domain List: 2a5f80db-676d-41f4-b305-1e8591266f94 8871e348-42da-447f-9193-70781b09730f

Re: external PSC 6.0 upgrade to 6.5 fails - Internal error occurs during pre-upgrade checks

andreir — Thu, 27 Sep 2018 09:26:49 GMT

Thanks, Rick!

Not sure what was wrong with my old password, but I changed administrator@vsphere.local password to a random 10 char string and was able to proceed with the upgrade.

external PSC 6.0 upgrade to 6.5 fails - Internal error occurs during pre-upgrade checks

andreir — Wed, 26 Sep 2018 19:11:22 GMT

Hi all,

trying to upgrade external PSC from 6.0.0.20000 to 6.5 U2, the new appliance is deployed, but then the upgrade process fails during the pre-upgrade check.

using cli-installer:

Precheck error: 1. Title: Internal error occurs during pre-upgrade checks.

Precheck error: 1. Suggested Resolution: Please search for these symptoms in the

VMware Knowledge Base for any known issues and possible resolutions. If none can

be found, collect a support bundle and open a support request.

Failed normalizing ip: psc04.vlab.local

(u'Failed to uninstall %(rpm)s on %(host)s: %(error)s', {'host':

u'psc04.vlab.local', 'rpm': u'vmware-upgrade-requirements-*', 'error':

CommandError(u"Failed to run and wait for command in guest with error 'Command

'/bin/rpm' exited with non-zero status 1'",)})

Collecting support bundle from source VM psc04.vlab.local ...

Failed normalizing ip: psc04.vlab.local

Collecting the support bundle from the deployed appliance...

Got error while running OVF Tool command: Errors encountered during the precheck

process. Correct the errors and provide a new appliance name in the template,

because you must deploy a new appliance.

using gui-installer:

Checked /var/log/vmware/upgrade on the source and see a bunch of sso errors and not a lot of other clues. Any idea how to overcome this issue?

/var/log/vmware/upgrade/requirements-upgrade-runner.log

...

2018-09-26T17:41:48.945Z ERROR bindings.sso_binding Cannot log-in to SSO admin service, because of Error: (vmodl.fault.InvalidRequest) {

dynamicType = <unset>,

dynamicProperty = (vmodl.DynamicProperty) [],

msg = "Request version 'urn:sso/version3_5' and namespace 'urn:sso' are not supported",

faultCause = <unset>,

faultMessage = (vmodl.LocalizableMessage) []

Traceback (most recent call last):

File "/var/tmp/vmware-upgrade-requirements/cis-upgrade-runner/py/bindings/sso_binding.py", line 138, in createSession

content = si.RetrieveServiceContent()

File "/var/tmp/vmware-upgrade-requirements/cis-upgrade-runner/libs/pyVmomi.zip/pyVmomi/VmomiSupport.py", line 557, in <lambda>

self.f(*(self.args + (obj,) + args), **kwargs)

File "/var/tmp/vmware-upgrade-requirements/cis-upgrade-runner/libs/pyVmomi.zip/pyVmomi/VmomiSupport.py", line 363, in _InvokeMethod

return self._stub.InvokeMethod(self, info, args)

File "/var/tmp/vmware-upgrade-requirements/cis-upgrade-runner/libs/pyVmomi.zip/pyVmomi/SoapAdapter.py", line 1338, in InvokeMethod

raise obj # pylint: disable-msg=E0702

vmodl.fault.InvalidRequest: (vmodl.fault.InvalidRequest) {

dynamicType = <unset>,

dynamicProperty = (vmodl.DynamicProperty) [],

msg = "Request version 'urn:sso/version3_5' and namespace 'urn:sso' are not supported",

faultCause = <unset>,

faultMessage = (vmodl.LocalizableMessage) []

}

2018-09-26T17:41:48.948Z WARNING bindings.sso_binding Could not retrieve service instance from SSO component using API version 'sso.version.version3_5'. Falling back to API version 'sso.version.version1'.

...

Other errors and warnings from requirements-upgrade-runner.log that might be relevant.

psc04:/var/log/vmware/upgrade # grep -iHE "error|warning" *

requirements-upgrade-runner.log:2018-09-26T17:39:33.286Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:33.287Z ERROR utils.featureState_utils Can not get AUTOMATED_VUM_UPGRADE feature state, default will be used

requirements-upgrade-runner.log:ImportError: No module named featureState

requirements-upgrade-runner.log:2018-09-26T17:39:33.302Z ERROR bindings.sso_binding Cannot log-in to SSO admin service, because of Error: (vmodl.fault.InvalidRequest) {

requirements-upgrade-runner.log:2018-09-26T17:39:33.305Z WARNING bindings.sso_binding Could not retrieve service instance from SSO component using API version 'sso.version.version3_5'. Falling back to API version 'sso.version.version1'.

requirements-upgrade-runner.log:2018-09-26T17:39:33.845Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:33.860Z ERROR bindings.sso_binding Cannot log-in to SSO admin service, because of Error: (vmodl.fault.InvalidRequest) {

requirements-upgrade-runner.log:2018-09-26T17:39:33.861Z WARNING bindings.sso_binding Could not retrieve service instance from SSO component using API version 'sso.version.version3_5'. Falling back to API version 'sso.version.version1'.

requirements-upgrade-runner.log:2018-09-26T17:39:33.948Z WARNING model.components_metadata Cannot find matching source metadata for provided:platform=Linux, version=6.0 and source-metadata=[{u'export-after': [u'vpxd'], u'platform': [u'Windows'], u'version': [u'5.5'], u'export-from': [u'com.vmware.vpxd']}]

requirements-upgrade-runner.log:2018-09-26T17:39:33.948Z WARNING model.components_metadata Invalid metadata: {u'destination-system': [{u'upgrade-script': u'vco', u'description': u'VMware vCenter Orchestrator component', u'component-display-name': u'VMware vCenter Orchestrator', u'platform': [u'Windows', u'Linux'], u'version': u'6.1', u'component-name': u'vco', u'optional': True}], u'source-system': [{u'export-after': [u'vpxd'], u'platform': [u'Windows'], u'version': [u'5.5'], u'export-from': [u'com.vmware.vpxd']}]}

requirements-upgrade-runner.log:2018-09-26T17:39:33.950Z WARNING model.components_graph Component com.vmware.sso depends on follow components set([u'com.vmware.common_logging', u'com.vmware.rdb']) but the system does not have metadata for them.

requirements-upgrade-runner.log:2018-09-26T17:39:33.951Z WARNING model.components_graph Component com.vmware.vmafd depends on follow components set([u'com.vmware.common_logging', u'com.vmware.rdb']) but the system does not have metadata for them.

requirements-upgrade-runner.log:2018-09-26T17:39:33.958Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:33.959Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:33.959Z WARNING model.components Component com.vmware.rbd won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.959Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:33.960Z WARNING model.components Component com.vmware.vpxd won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.960Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:33.960Z WARNING model.components Component com.vmware.vcdb won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.960Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:33.961Z WARNING model.components Component com.vmware.eam won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.961Z WARNING model.components Component com.vmware.ngc won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.961Z WARNING model.components Component com.vmware.netdump won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.962Z WARNING model.components Component com.vmware.is won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.962Z WARNING model.components Component com.vmware.vsan-health won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.962Z WARNING model.components Component com.vmware.vcIntegrity won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.962Z WARNING model.components Component com.vmware.sps won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.963Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:33.964Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:33.964Z WARNING model.components Component com.vmware.cls won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:39:33.977Z ERROR bindings.sso_binding Cannot log-in to SSO admin service, because of Error: (vmodl.fault.InvalidRequest) {

requirements-upgrade-runner.log:2018-09-26T17:39:33.978Z WARNING bindings.sso_binding Could not retrieve service instance from SSO component using API version 'sso.version.version3_5'. Falling back to API version 'sso.version.version1'.

requirements-upgrade-runner.log:2018-09-26T17:39:34.43Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:39:52.466Z WARNING upgrade.states.preupgrade_state vpxd_servicecfg does not exist, assume local storage

requirements-upgrade-runner.log:2018-09-26T17:39:52.638Z WARNING deployer.migration_env_deployer Could not unregister component com.vmware.migrate-connector.127.0.0.1 located on localhost as extension. Exception: -- 'NoneType' object has no attribute 'content'

requirements-upgrade-runner.log:2018-09-26T17:41:33.413Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:41:33.414Z ERROR utils.featureState_utils Can not get AUTOMATED_VUM_UPGRADE feature state, default will be used

requirements-upgrade-runner.log:ImportError: No module named featureState

requirements-upgrade-runner.log:2018-09-26T17:41:33.432Z ERROR bindings.sso_binding Cannot log-in to SSO admin service, because of Error: (vmodl.fault.InvalidRequest) {

requirements-upgrade-runner.log:2018-09-26T17:41:33.435Z WARNING bindings.sso_binding Could not retrieve service instance from SSO component using API version 'sso.version.version3_5'. Falling back to API version 'sso.version.version1'.

requirements-upgrade-runner.log:2018-09-26T17:41:33.685Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:41:33.703Z ERROR bindings.sso_binding Cannot log-in to SSO admin service, because of Error: (vmodl.fault.InvalidRequest) {

requirements-upgrade-runner.log:2018-09-26T17:41:33.705Z WARNING bindings.sso_binding Could not retrieve service instance from SSO component using API version 'sso.version.version3_5'. Falling back to API version 'sso.version.version1'.

requirements-upgrade-runner.log:2018-09-26T17:41:33.797Z WARNING model.components_metadata Cannot find matching source metadata for provided:platform=Linux, version=6.0 and source-metadata=[{u'export-after': [u'vpxd'], u'platform': [u'Windows'], u'version': [u'5.5'], u'export-from': [u'com.vmware.vpxd']}]

requirements-upgrade-runner.log:2018-09-26T17:41:33.798Z WARNING model.components_metadata Invalid metadata: {u'destination-system': [{u'upgrade-script': u'vco', u'description': u'VMware vCenter Orchestrator component', u'component-display-name': u'VMware vCenter Orchestrator', u'platform': [u'Windows', u'Linux'], u'version': u'6.1', u'component-name': u'vco', u'optional': True}], u'source-system': [{u'export-after': [u'vpxd'], u'platform': [u'Windows'], u'version': [u'5.5'], u'export-from': [u'com.vmware.vpxd']}]}

requirements-upgrade-runner.log:2018-09-26T17:41:33.799Z WARNING model.components_graph Component com.vmware.sso depends on follow components set([u'com.vmware.common_logging', u'com.vmware.rdb']) but the system does not have metadata for them.

requirements-upgrade-runner.log:2018-09-26T17:41:33.800Z WARNING model.components_graph Component com.vmware.vmafd depends on follow components set([u'com.vmware.common_logging', u'com.vmware.rdb']) but the system does not have metadata for them.

requirements-upgrade-runner.log:2018-09-26T17:41:33.807Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:41:33.808Z WARNING model.components Component com.vmware.rbd won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.808Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:41:33.808Z WARNING model.components Component com.vmware.vpxd won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.809Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:41:33.809Z WARNING model.components Component com.vmware.vcdb won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.809Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:41:33.809Z WARNING model.components Component com.vmware.eam won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.810Z WARNING model.components Component com.vmware.ngc won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.810Z WARNING model.components Component com.vmware.netdump won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.810Z WARNING model.components Component com.vmware.is won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.810Z WARNING model.components Component com.vmware.vsan-health won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.811Z WARNING model.components Component com.vmware.vcIntegrity won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.811Z WARNING model.components Component com.vmware.sps won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.811Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:41:33.812Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:41:33.812Z WARNING model.components Component com.vmware.cls won't be upgraded

requirements-upgrade-runner.log:2018-09-26T17:41:33.825Z ERROR bindings.sso_binding Cannot log-in to SSO admin service, because of Error: (vmodl.fault.InvalidRequest) {

requirements-upgrade-runner.log:2018-09-26T17:41:33.826Z WARNING bindings.sso_binding Could not retrieve service instance from SSO component using API version 'sso.version.version3_5'. Falling back to API version 'sso.version.version1'.

requirements-upgrade-runner.log:2018-09-26T17:41:33.888Z WARNING networking_utils Could not find address info for 127.0.0.1

requirements-upgrade-runner.log:2018-09-26T17:41:47.190Z WARNING upgrade.states.preupgrade_state vpxd_servicecfg does not exist, assume local storage

requirements-upgrade-runner.log:2018-09-26T17:41:47.356Z WARNING deployer.migration_env_deployer Could not unregister component com.vmware.migrate-connector.127.0.0.1 located on localhost as extension. Exception: -- 'NoneType' object has no attribute 'content'

upgrade-linux-requirements.log:2018-09-26T17:39:30.649Z ERROR utils.featureState_utils Can not get AUTOMATED_VUM_UPGRADE feature state, default will be used

upgrade-linux-requirements.log:ImportError: No module named featureState

upgrade-linux-requirements.log:2018-09-26T17:39:54.513Z ERROR bindings.sso_binding Cannot log-in to SSO admin service, because of Error: (vmodl.fault.InvalidRequest) {

upgrade-linux-requirements.log:2018-09-26T17:39:54.527Z WARNING bindings.sso_binding Could not retrieve service instance from SSO component using API version 'sso.version.version3_5'. Falling back to API version 'sso.version.version1'.

upgrade-linux-requirements.log:2018-09-26T17:41:31.706Z ERROR utils.featureState_utils Can not get AUTOMATED_VUM_UPGRADE feature state, default will be used

upgrade-linux-requirements.log:ImportError: No module named featureState

upgrade-linux-requirements.log:2018-09-26T17:41:48.945Z ERROR bindings.sso_binding Cannot log-in to SSO admin service, because of Error: (vmodl.fault.InvalidRequest) {

upgrade-linux-requirements.log:2018-09-26T17:41:48.948Z WARNING bindings.sso_binding Could not retrieve service instance from SSO component using API version 'sso.version.version3_5'. Falling back to API version 'sso.version.version1'.

Re: vCenter vsphere-client service fails with Java memory error

andreir — Wed, 21 Mar 2018 16:35:42 GMT

Unfortunately I was unable to resolve it with 6.0 version. I had a lot of third-party plugins in the vCenter (this was a lab), I suspect one was leaking memory. My solution was to upgrade to 6.5.

CIP proxy fails to start

andreir — Wed, 13 Dec 2017 19:01:06 GMT

Hi all,

Running the latest vCenter 6.5u1, installed Enhanced Authentication plugin 6.5, CIP proxy service fails to start:

[2017-12-13 11:56:42] [UNKN] VMware CIP Message Proxy Version: 6.5.0, Build # 7192315

[2017-12-13 11:56:42] [INFO] Log Level: info

[2017-12-13 11:56:42] [INFO] Command Line: C:\Program Files (x86)\VMware\Plug-in Service\vmware-cip-msg-proxy.exe

[2017-12-13 11:56:42] [INFO] App Path: C:\Program Files (x86)\VMware\Plug-in Service\vmware-cip-msg-proxy.exe

[2017-12-13 11:56:42] [INFO] Service Dir: C:\Program Files (x86)\VMware\Plug-in Service

[2017-12-13 11:56:42] [INFO] Process [EM1C-3Iq2-U3Zv-OEx9]: Starting [async] "C:\Program Files (x86)\VMware\Plug-in Service\vmware-cip-init.exe"

[2017-12-13 11:56:42] [INFO] Process [EM1C-3Iq2-U3Zv-OEx9]: Process created: "C:\Program Files (x86)\VMware\Plug-in Service\vmware-cip-init.exe" --dh2048

[2017-12-13 11:56:42] [INFO] Process [EM1C-3Iq2-U3Zv-OEx9]: Waiting for process to exit...

[2017-12-13 11:56:42] [INFO] Process [EM1C-3Iq2-U3Zv-OEx9]: Thread has been terminated.

[2017-12-13 11:56:42] [INFO] Process [EM1C-3Iq2-U3Zv-OEx9]: Process has exited.

[2017-12-13 11:56:42] [INFO] Proxy server start requested...

[2017-12-13 11:56:42] [INFO] Proxy server thread started.

[2017-12-13 11:56:42] [INFO] Main Web Socket [8094]: run() called.

[2017-12-13 11:56:42] [INFO] Main Web Socket [8094]: Starting...

[2017-12-13 11:56:45] [ERRO] Main Web Socket [8094]: Start Accept Failed With Exception: resolve: No such host is known

[2017-12-13 11:56:45] [INFO] Main Web Socket [8094]: run() exited, will run on background thread.

[2017-12-13 11:56:45] [INFO] Main Web Socket [8094]: Thread Started.

[2017-12-13 11:56:45] [INFO] Main Web Socket [8094]: Thread Stopped.

[2017-12-13 11:56:45] [ERRO] SessionManager web socket crashed after 0 seconds.

[2017-12-13 11:56:45] [ERRO] SessionManager web socket crashed again, and is not recoverable, exiting.

[2017-12-13 11:56:45] [ERRO] Proxy server crashed.

Any ideas?

Re: Force resolution on CentOS 7 desktop

andreir — Mon, 11 Dec 2017 23:36:22 GMT

So I have "Allow display scaling" enabled in the View client and I've noticed that if I connect to the Linux desktop and get 3000x2000 resolution, I can then disable and enable "Allow display scaling" in the View client and the resolution then is changed to 1500x1000.

This looks like a bug in the agent - the display scaling setting just does not work on the initial connection but manually toggling it on the existing connection achieves the desired result.

Re: Force resolution on CentOS 7 desktop

andreir — Mon, 11 Dec 2017 22:55:05 GMT

Sorry, forgot to mention that I'm connecting using View client on Windows 10

Re: Force resolution on CentOS 7 desktop

andreir — Mon, 11 Dec 2017 22:31:25 GMT

Well, spoke too soon. It was good for a bit but after a reconnect the View client connection is again using 3000x2000 resolution. So setting the svga parameters in .vmx config file did not help...

Any other way to force the lower resolution in Linux Horizon View?

Re: Force resolution on CentOS 7 desktop

andreir — Mon, 11 Dec 2017 20:25:13 GMT

This helped to set the max Linux guest resolution to 1920x1024:

https://docs.vmware.com/en/VMware-Horizon-7/7.3/linux-desktops-setup.pdf

page 23:

modify VM advanced options and set the following:

svga.autodetect="false"

svga.maxHeight="1024"

svga.maxWidth="1920"