I too have been trying to set up a 3rd Party SAML Authenticator, but seeing that your question from many many moons ago hasn't been answered, I suspect mine too will go the way of /dev/null:
Error 404 while attempting SAML authentication to Horizon View environment!
I wonder why even mention 3rd Party SAML Authenticators in the documentation if they are then given nothing more than lip service!!!
Cheers,
ak.
driver version 1.5.8 is not the newest. Install version 2.0.7
Most likely the problem is this.
Not yet but I do have a support case open. So far though I've not actually interacted with an engineer. Hopefully on Monday.
Hi,
Please check the view agent logs located in C:\ProgramData\VMware\VDM\logs inside the virtual machine you are trying to connect to.
Also mentioned OS (Windows 10-1709) is not compatible with Horizon 7.3.1, Please check VMware Knowledge Base .
Vxlan Control Plane is how the Mac and Arp Tables are formed, and the mechanism may change according to the technology. The Arp Suppression Mechanism may change for each of these Control Plane technologies.
The VXLAN Control Planes may be :
The reason why Multicast has no arp suppression, could be because there is no inherent mechanismon Multicast to replicate or synchronize the Arp tables on different VTEP Hosts. It is a technology to deliver packets to more than one destination similar to radio stations, tv channels. Arp Protocol is designed to learn MAC address of a known IP address in the same subnet such as default gateway. Since VXLAN needs arp protocol learning because it is a Overlay Tunneling Protocol over L3 subnets, without any enhancement there is no way of creating a VXLAN packet to a remote VTEP on another IP subnet.
Multicast is a development for BUM Packets because sending a singleMulticast BUM Frame and receiving of this frame by only "interested" hosts provides scalability and efficiency wrt to blindly broadcasting or flooding this packet to every other VTEP Host.
https://blogs.vmware.com/vsphere/2013/04/vxlan-series-different-components-part-1.html
https://blogs.vmware.com/vsphere/2013/05/vxlan-series-multicast-basics-part-2.html
https://blogs.vmware.com/vsphere/2013/05/vxlan-series-multicast-usage-in-vxlan-part-3.html
MP-BGP acts as the "Controller Cluster", similar to NSX Controller-Cluster. In this mode every VTEP joins the BGP Protocol, and similar to distribution of IP Routing table, MAC, VTEP and ARP tables are Synchronized or Replicated through MP-BGP Protocol. So in this mode of control plane every VTEP (In that case TOR Physical Switches) has the same view of these tables. Since the VTEP is part of the "Controller Cluster", there is no need for other specific Controller Nodes deployed as whole of the table is already on the VTEP. In this mode VTEP-1 knows the Arp Request asked by VTEP-2 and received through VTEP-3 because VTEP-3 has redistributed this Arp entry during first visibility either by itself broadcasting arp or for silent hosts after first asked for. If there are 10 VTEPs, all of them has the same ARP table.
In this mode Arp Suppression is an enhancement over Multicast similar to Controllers.
Since Physical switches need special ASICs for VXLAN Processing and MP-BGP, managing MPBGP EVPN control plane is complex and expensive on hardware side. NSX decouples this complexity by providing Controllers to handle these mechanisms and allows the Underlying Physical Switch Fabric to be simpler and more scalable. The Underlying Physical switches don't have to support Protocols such as Multicast PIM, VXLAN, MP-BGP EVPN. This makes it possible to provide new features and innovation through a software upgrade without changing the Physical Switches. (It is way faster and easier to deploy NSX on an existing Vsphere Infrastructure rather than changing the Underlying Physical switches and Cabling). It also allows to use different physical hardware on different sites rather than relying on a single hardware solution.
These links could provide more detailed abouth these mechanisms:
http://www.routetocloud.com/2014/12/nsx-v-ip-discovery/
The UWA will send out query to NSX controller and ask if he know MAC2, since controller already know this Controller will send unicast message back to VM1 with MAC2, the ARP broadcast message will not send out to all VM’s in VXLAN 5001.
Note: There is 3 min timer in NSX controller for ARP query, if host send same query in this time frame the controller ignore this request and broadcast message will be send out to all VM in the logical switch
ARP suppression is an enhancement provided by the MP-BGP EVPN control plane to reduce network flooding caused by broadcast traffic from ARP requests.
When ARP suppression is enabled for a VNI, its VTEPs each maintain an ARP suppression cache table for known IP hosts and their associated MAC addresses in the VNI segment. As illustrated in Figure 10, when an end host in the VNI sends an ARP request for another end-host IP address, its local VTEP intercepts the ARP request and checks for the ARP-resolved IP address in its ARP suppression cache table. If it finds a match, the local VTEP sends an ARP response on behalf of the remote end host. The local host then learns the MAC address of the remote host in the ARP response. If the local VTEP doesn’t have the ARP-resolved IP address in its ARP suppression table, it floods the ARP request to the other VTEPs in the VNI. This ARP flooding can occur for the initial ARP request to a silent host in the network. The VTEPs in the network don’t see any traffic from the silent host until another host sends an ARP request for its IP address, and an ARP response is sent back. After the local VTEP learns about the MAC and IP addresses of the silent host, the information is distributed through the MP-BGP EVPN control plane to all other VTEPs. Any subsequent ARP requests do not need to be flooded.
Because most end hosts send GARP or RARP requests to announce themselves to the network immediately after they come online, the local VTEP immediately has the opportunity to learn their MAC and IP addresses and distribute this information to other VTEPs through the MP-BGP EVPN control plane. Therefore, most active IP hosts in VXLAN EVPN should be learned by the VTEPs either through local learning or control-plane-based remote learning. As a result, ARP suppression reduces the network flooding caused by host ARP learning behavior
https://adamraffe.com/2013/06/24/enhanced-vxlan-who-needs-multicast/
https://docs.cumulusnetworks.com/display/DOCS/Ethernet+Virtual+Private+Network+-+EVPN
Ethernet Virtual Private Network (EVPN) is a standards-based control plane for VXLAN defined in RFC 7432 and draft-ietf-bess-evpn-overlay that allows for building and deploying VXLANs at scale. It relies on multi-protocol BGP (MP-BGP) for exchanging information and is based on BGP-MPLS IP VPNs (RFC 4364). Hence, it has provisions to enable not only bridging between end systems in the same layer 2 segment but also routing between different segments (subnets). There is also inherent support for multi-tenancy. EVPN is often referred to as the means of implementing controller-less VXLAN.
Cumulus Linux fully supports EVPN as the control plane for VXLAN, including for both intra-subnet bridging and inter-subnet routing. Key features include:
https://www.arista.com/assets/data/pdf/Whitepapers/VXLAN_Scaling_Data_Center_Designs.pdf
VXLAN Implementation The network infrastructure must support the following to support VXLANS: • Multicast support: IGMP and PIM • Layer 3 routing protocol: OSPF, BGP, IS-IS For the most part, networking devices process VXLAN traffic transparently. That is, IP encapsulated traffic is switched or routed as any IP traffic would be. VXLAN gateways, also called Virtual Tunnel End Points (VTEP), provide the encapsulating/de-encapsulating services central to VXLAN. VTEPS can be virtual bridges in the hypervisor, VXLAN aware VM applications or VXLAN capable switching hardware. VTEPs are key to virtualizing networks across the existing data center infrastructure.
With VXLAN, BUM traffic still exists and still needs to be sent to the unknown destination(s) in the Layer2 domain. As previously discussed in the fundamentals section about unicast replication (HER), there are two ways to populate the unicast HER flood list: manually (in CLI), or automatically with CloudVision (CVX with the VXLAN service). In the below illustration, Host A sends a frame destined to Host D, but MAC D is unknown by VTEP1. VTEP1 will therefore follow the flooding behaviour expected for BUM traffic, and replicate to the VTEP IP addresses listed in VTEP1’s flood-list: VTEP2 and VTEP3.
Hi,
Please make sure the powershell Execution Policy has been set properly on your system (Set-ExecutionPolicy ), Also please note that there are 2 versions of powershell on system (32 and 64bit) and each has it's own Execution policy. You can check the current policy with Get-Executionpolicy command in powershell.
Hi kyle901 & stiftelsen,
I have the same problem in vSAN cluster.
How do I check if port 9080 is blocked?
I ran the following commands on the ESXi:
nc -z 10.76.4.209 9080
Connection to 10.76.4.209 9080 port [tcp/*] succeeded!
esxcli network ip connection list | grep 9080
tcp 0 0 :::9080 :::0 LISTEN 67874 newreno ioFilterVPServer
Is this mean the port is enabled?
Thanks
Any chance that somebody had the same problem involving EVE-NG and found a solution? I'm running into the same problem, testing currently but no solution so far.
Thanks!
Hello all,
I have a vSphere Essentials 5.1 installed on a SD card, and all the VMs in the internal storage of the server. I want to purchase new license for 6.5 version. Because of versions distance, I prefer to do a fresh install not an upgrade. Which is the correct procedure to do it?
Can I simply format SD, install VMware on it, and attach the internal datastore to see all my VMs?
Thanks!
Hi All,
I need some clarification around VCP-NV exam. I'm thinking of taking path 2 of the certification as i already hold cisco CCNP. (https://mylearn.vmware.com/mgrReg/plan.cfm?plan=64294&ui=www_cert )
The question I've got, will they stop me from takin ghte vcp-nv exam without prior completing the Vsphere Foundation exam ?
I know i won't be certified until i do the vSPhere Foundation Exam, but having not done the VSphere foundation exam, will it stop me from sitting the VCP-NV exam ?
Thank you
This is a product limitation in vCenter 6.5 Update 1 and below. This is because of a regression in 6.5 where Content Library API call thread management, such that all API call threads in the relevant thread pool are used up and no running threads can be released when the number of disks is more than 6 during VM/VApp export or OVF template deployment.
The maximum supported amount of disks (.vmdk files) contained in a vApp or virtual machine that is being cloned to template in a Content Library as of vCenter Server 6.5 Update 1 is 6.
We recently received 8 brand new HPE DL380 Gen10 servers with the HPE branded cards (562SFP+)
We are experiencing the same issues as everyone else. In the ESXi console we associated two of these nics for the management network. After assigning an IP address, mask, gateway, and DNS servers we restart a host. During the restart we have a continuous ping going to the management network IP address. Part way through booting up the ping returns. After about 30 seconds the ping drops and never comes back. If we remove one of the nics, the ping returns. In other words, with two of these nics as part of the management network, they will not pass traffic. We are on driver version 1.5.8 and firmware version 10.2.5
Any solutions yet? I have an open ticket with VMWare and HPE for nearly two weeks
Looking at the top of the stack trace it shows dtrace_psinfo_alloc so I am guessing the crash is related to the dtrace module.
Do you know if dtrace enabled in an OEL VM requires virtual performance counters (VPMC) to be enabled on the VM CPU settings? I don't think version 12.5.x would be able to initialise the VPMC properly for host with Kaby Lake/Coffee Lake CPUs. Did you have to disable the VPMC in order to power up the OEL VM on the i7-8700 host?
VPMC is one of those features where the hypervisor will need to do some extra stuff before it can be available in the VM.
If you look at the vmware.log (look for the text codename), you will likely find the codename is probably Pentium 3 or Pentium (unknown)
| vmx| I125: hostCPUID codename:
While the codename in itself is not important, it does indicate that Workstation Pro hypervisor won't be able to initialise the correct microarchitecture for VPMC inside a VM.
If you don't use dtrace within the VM, you could try removing dtrace (using the i7-4702MQ host) from the OEL VM and see whether that allows you to power up the OEL VM on the i7-8700 host.
Is the domain controller VM running on the same ESXi host as the Terminal Server and Exchange Servers?
Do you see the following lines in the vmware.log of the DC VM?
| vmx| I125: Capability Found: cpuid.STIBP = 0x1
| vmx| I125: Capability Found: cpuid.IBPB = 0x1
| vmx| I125: Capability Found: cpuid.IBRS = 0x1
If you don't see those lines in the vmware.log and it is running on the same host as the Terminal/Exchange server VMs, somehow the Spectre microcode is masked/disabled for the DC VM.
The ESXi650-201803402-BG (microcode update) does not cover Westmere CPUs based on the table in KB52085 https://kb.vmware.com/s/article/52085
So you would need to have the BIOS update from HP to have the Spectre microcode. Intel did release the microcode update for Westmere EP series.
The FeatureMaskOverride registry settings for Windows requires a reboot in order to take effect (whether to enable/disable).
Perhaps you can attach the vmware.log of the DC VM if you are still stuck with the same problem with the DC VM.
I wonder this happens to others.
1. Connect to a remote Windows PC (Com2) with an RDP client from a PC (Com1).
2. Start a guest OS on Vmware Workstation on Com2.
3. Start a server process on the guest.
4. Close the RDP client on Com1.
5. The guest randomly seems to stop as if it was put to sleep. I know this because the server process is not responding to requests from Com1.
6. The guest seems to start again when an RDP client is connected to Com2 again, and view the guest's screen on Vmware Workstation. I know this because the server process responds again.
Of course, system idle sleep has been disabled on both Com2 and the guest.
Once again, if your datastore is out of space or close thereto, you must increase space or migrate VMs off of it in order to consolidate those snapshots.
Ok, Paul. If you do hear back and get some resolution on it, I'd be very interested to know if this is acknowledged as a defect or if something else is going on.
That is bizzarre!
Running on the same ESXi host (so that means the microcode is present and active in the host hardware), OK for 2 VMs but not the DC VM. Running on same ESXi host also precludes the /etc/vmware/config mask from the "Intel Sightings" KB as the culprit.
How about the DC VM hardware compatibility setting? Is it also version 13 (supported by ESXi 6.5) or at least same as the TS/Exchange VMs? I think the recommended minimum is version 9.
Other than HW compability version, I can't think of any other possible reason why. But the fact the stibp, ipbp, and ibrs capabilities show up in the vmware.log that means the ESXi hypervisor found the microcode update and should be exposed to the VM.
Alternatively, you could remove those registry settings; because those registry settings were really introduced to mitigate the crashing in January (just like the VMware Intel Sightings KB).
Bluefirestorm you are the hero!!!
The VM still has had version 8... after upgrading to V13 everything is fine!
What a bloody rookie mistake...
I throw myself reverential into the dust!
Anyway - thanks again!