Vmware Esxi 7.0.2 Download Iso

1 view

Skip to first unread message

Waneta

unread,

Aug 3, 2024, 11:52:55 AM8/3/24

to tumbrajdpreleth

When i'm going to enable on my aruba switch LACP in port 2 (that it is my last server's port in my nic teaming), my esxi web server stop to work, and i can't ping my esxi ip until i free one port from aruba LACP port trunk.

Correct: LACP is supported only on vSphere Distributed Switch (so, switch side, you need a LACP Trunk to be configured)...if you are using Route based on IP Hash then you're probably using vSphere Standard Switch...thus use a Non Protocol (non-LACP) Trunk switch side, as suggested.

The AOS virtual appliance installation guide says to use LACP on teamed vSwitch uplinks - But since this is not a VMWare BP, and poses a variety of issues of its own on the VMWare side, Teaming method should be Source IP Hashing (I think? Maybe MAC hashing? I need to do some further experimenting to be sure). If you encounter an issue where clients are rapidly associating/disassociating, it's likely something to do with your switch uplink teaming on your anchor controller going haywire... Took me hours to figure that out when I first encountered it.

Teamed uplinks are not bridged internally within VMWare so they don't pose a spanning tree issue with your uplink switch. You can have two ports with identical config and assigned as uplinks to the vSwitch, and it will not cause the switch to freak out and put one port in blocking mode. This is vastly easier than trying to LACP the only two links on the system - I highly recommend having a separate vmkernel interface on the box just to avoid management headaches. This is very similar to how Windows does NIC teaming.

While not using VLAN 1 is considered best practice, remember that VMWare does not allow specifying a native VLAN on a trunked switch, so whatever you use as native VLAN on your uplinks will be the the native VLAN within VMWare, and is untagged. This gets a little quirky with port groups set for VLAN trunking. If your switch supports both tagged/untagged traffic on the same VLAN (not uncommon with data center grade switches), you can have a trunked port group without worrying about this, but otherwise you'll need to make sure your VLANs within AOS are set correctly.

So if you use VLAN 4000 as your default VLAN and it is untagged on the uplinks, you need create a port group with no VLAN specified, or a trunked one (VLAN 4095 in VMWare designates a trunked port group), and when configuring your AOS device, you can still set the management VLAN as 4000 and either set the port to access mode, or trunked, with 4000 native.

Note that while AOS refers to these interfaces as "gigabitEthernet", VMWare presents them to the guest OS as 10G. The physical controller/conductor appliances also refer to them as "gigabitEthernet" even when they are SFP+ with a 10G module.

Since they are functionally 10G interfaces in VMWare, you won't need to set up a portchannel (and trust me, you really don't want to go there... If you think LACP on the uplinks is wonky, doing it on virtual ports is even more so)

The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

[1] Per the Security Configuration Guides for VMware vSphere, VMware now recommends disabling the OpenSLP service in ESXi if it is not used. For more information, see our blog posting: -the-vmware-vsphere-security-configuration-guides.html

The vSphere Client (HTML5) contains an SSRF (Server Side Request Forgery) vulnerability due to improper validation of URLs in a vCenter Server plugin. VMware has evaluated the severity of this issue to be in the Moderate severity range with a maximum CVSSv3 base score of 5.3.

I think you can add the extension "VMware (remote monitoring)" from Hub to your environment to get metrics related to datastore information. And then you can create a metric event associating it to an alerting profile and a notification.

If you would havent DDUs availabled to add the extension, maybe you could use the builtin metric "builtin:cloud.vmware.hypervisor.availability" for creating a metric event to alert vmware connectivity.