vCenter http request rate

PR: https://bugzilla.eng.vmware.com/show_bug.cgi?id=2088939

Resil jsem dneska limitaci vCentra pro spousteni API (ansible/powercli) prikazu. Reseni je relativne jednoduche - navysit v souboru: /etc/vmware-vapi/endpoint.properties hodnotu http.request.rate.count=360 na treba 1000 a restartovat  vmware-vapi-endpoint sluzbu

Number of vCenter API requests
Pocet API volani do vCentra

vLCM versus VxRAIL

Q: with the introduction of vLCM with readynodes, what would the value out of selling VxRail ?

A: Though vLCM provides firmware support, it doesn’t provide pre-validated and pre-integrated bundles, which VxRail does. Our customers have told us that this is a big pain point. VxRail images are getting customer from one valid image/driver/firmware state to another valid state.

VxRail provides other value such as enhanced phone home support and additional automation such as auto-buildout of clusters.

vSAN/DRS awareness to be introduced in vSAN/vSphere 7.0! (NOT RELEASE in 7.0)

Originally piblished here ... 

http://www.yellow-bricks.com/2020/03/19/vsan-drs-awareness-to-be-introduced-in-vsan-vsphere-7-0/

It was briefly mentioned here, but I figured I would elaborate on this new cool feature for vSAN Stretched Clusters which is DRS Awareness of vSAN Stretched Clusters. So what does this mean? Well, it is fairly straight forward. DRS will take vSAN resync traffic into consideration when the DRS algorithm runs. I can probably explain best by talking through a scenario:

• vSAN Stretched Cluster environment with 4 hosts and a witness
• VMs running in Preferred and in Secondary
• VMs configured with "should rules" to stay within their fault domain
• ISL between "data locations" is impacted
• HA has restarted the VMs of the secondary site in the preferred site
• ISL is now restored

What would happen without DRS awareness of vSAN stretched clusters is that DRS would automatically migrate VMs back to the Secondary site as soon as it becomes available. DRS runs every minute in vSphere 7.0 so it is very likely that vSAN is still resyncing data. The problem with this is two-fold:

1. The vMotion process will slow down the resync of data temporarily
2. Blocks which have not been resynced and are being read by the VM will need to be fetched from the remote location

As you can imagine this is an undesired situation. As such in vSphere / vSAN 7.0 a whole new level of integration is introduced between DRS and vSAN. Now DRS will be aware of what is happening on the vSAN layer. If vSAN is syncing a particular component of a virtual machine, then DRS will not move the VM back! It will wait until the resync has completed and then move the VM back. This ensures that the migration won't conflict with the resync, and of course that when the VM is migrated that it will have "site read locality".

It is a feature our team had been asking for and which was tested within VMware Cloud on AWS, and I am happy to see it made it into the "regular" vSphere release.