The only way to try to contain VMotion traffic the same fabric would be to set the vmnic uplink preference for the vmotion vmkernel so that vMotion always "prefers" to use the same Fabric uplink (A or B).
This is what most folks do. VMotion is not constant traffic, just bursty - so confining it to one fabric interfonnect is a good design choice if you don't want it to traverse northbound of the UCS domain.
No need to change anything on UCSM side for the vMotion requirment. All required is that the vmnic which corresponds to FI-A is set as primary on each host for the VMkernel used for vMotion. This keeps all vmotion traffic local to one FI without leaving the system.
At any time if you lost an adapter, IOM or FI, they traffic would failover to the standby vmnic assigned to the vmkernel - so you will have full redundancy - you're simply setting a sticky "preference" of which link to use. In the case where you lost IOM-A on Chassis 2, that VMotion traffic would then traverse the northbound network to reach the other fabric - not a big deal as vMotion is not that bandwidth demanding.
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...