Courts administrators notice vMotion of a case-management VM during host maintenance. Where should they classify that traffic when writing Distributed Firewall application policy?

Courts administrators who see vMotion of a case-management VM during host maintenance should classify that traffic as host management on the vMotion VMkernel, not as guest Application Distributed Firewall. vMotion is the moving van on the loading dock—hypervisor live migration—not clerks exchanging case data inside the guest application. Writing guest Application Distributed Firewall rules on the VM vNIC for vMotion ports fails by concept because vMotion does not traverse the guest vNIC application path; it uses the VMkernel vMotion interface, so Application Distributed Firewall on guest ports neither correctly classifies nor reliably controls that migration traffic. Binding Identity Firewall rules to the clerk who last logged into the VM fails because Identity Firewall keys off interactive user identity for guest flows, not kernel migration events, and last-login identity is unrelated to host maintenance vMotion. Treating vMotion as Gateway Firewall north-south because vMotion leaves the building fails because intra-cluster or metro vMotion is not citizen north-south application publication and should not be designed as Edge VIP traffic. Exam caveat: vMotion is VMkernel management-plane traffic; keep it out of guest Application Distributed Firewall, Identity Firewall user binding, and north-south Gateway Firewall application designs. Operational check: confirm vMotion VMkernel networking and isolation separately from Application Distributed Firewall sections, ensure no guest rules pretend to own vMotion ports for case-management VMs, validate a maintenance vMotion still succeeds under application micro-segmentation, and document the separation in the courts NSX design notes.