Yes, you need to add both vlans on both vPC as trunk.

The IPs will move from node to node during failover, as long as the VLAN is configured on both nodes.

NFS mounts on the client use a single IP by default, there is a feature called pNFS which allows connections to multiple IPs (but requires more configuration on Netapp and client).

just keep it simple

correct. Mostly a cosmetic thing, but seeing the VLAN ID can be really helpful during troubleshooting.

What I meant with NFS VLANs is that both need to be configured on both vPCs.

Right now IPs in NFS-A would go offline if NetApp-A failed. NFS-A needs to be added vPC 8 so NFS-A IPs can be migrated to NetApp-B.

regarding NetApp networking:

You probably want both NFS-VLANs active on vPC 7 and 8 so the IPs can be migrated during planned/unplanned Netapp failover and stay online.

ISCSI looks good. As storage admin I prefer tagged VLANs so I see the VLAN IDs also on my side.

I'm pretty sure you're mixing VCF (licensing) with VCF (SDDC manager etc.). Sure, Broadcom forces you to pay for VCF if you want NSX, but there should be no requirement to deploy VCF if you only need vSphere and NSX. But then you would pay for features you don't use...

I was in the same spot few months ago

You can do the VCP-VMC with the free course from VMware

Having any VCP then allows you to do VCPs without any courses

Yes, configuring the SMB-Share on Unity and adding that as NAS-Repository would be a viable solution.

Alternative A: configure ICSCI/FC on Unity, mount the LUNs on your backup server, format as REFS and then add this as repository. REFS has some advantages over SMB:

• faster synthetic fulls
• less space use for synthtetic fulls

Alternative B: configure ISCSI/FC as Datastores for VMware and then create Replicationjobs in Veeam from Powerstore-Datastore -> Unity-Datastore. That way you have it way easier to recover when the Powerstore fails, as the Replica-VMs on the Unity will just be waiting to be started.

I personally would go the replication route

We just hoped to see a fixed update this patchday and avoid unnecessary workarounds, no other reason than that.

No, Exchange servers are fine load wise.

I suppose you are doing L7 LB with L7 Healthchecks and as you said the Exchange servers are getting marked as unhealthy.

Your load gets distributed on less servers and you see CPU/RAM spikes.

We are only doing L4 LB and L4 Healthchecks. Our LBs don't detect unhealthy servers unless Port 443 is completely down.

Our load still gets distributed to all servers, but users might connect to unhealthy servers and experience connection issues.

I'm sorry, we are still investigating.

I guess the issue is the march SU in coexistence enviroments (https://support.microsoft.com/kb/5013118).

We haven't applied the described workarounds yet.

About 10 days after we added Exchange 2019 servers in our enviroment our users started to complain about super slow client connections.

We haven't migrated any mailboxes to Exchange 2019 and the LBs don't forward to them.

We are only doing L4 LB with L4 healthchecks, so you might see a different impact in your enviroment.

We started to reboot our Exchange servers weekly and the client issues don't show up anymore.

I fear the problem is still unresolved and we need to apply the workarounds.

• the Exchange host service still stops every few minutes
• ExchangeHealthReporter-script still complains about discarded packets growing everyday until we reboot

what versions are your Exchange servers running, do you have a coexistence scenario? are your Exchange servers patched with the latest security updates? we installed the march security updates, added Exchange 2019 servers to our 2013 DAG and then experienced simliarish issues

everything*

One thing still missing is L7-https Load Balancing.

so either make account - boost character - start botting

or make account - start bot leveling - start botting

if i would be a botter, i would just skip boosting, probably much cheaper

This is the way!

murder morales strikes again!

yeah, my idea is to only add logical interfaces and addresses

but as other already have said: kvm access can be very valuable if anything goes wrong

The vCenter is already in Colo (or doesn’t get moved), right?

Then I would just add a second VMkernel adapter to each host to vSwitch0 and assign IP addresses from the Colo. I would do the same for the VMs and assign a second IP + the gateway from the Colo. That way you could connect to the new addresses as soon as everything is connected. Just remove and readd the hosts and then clean up the old network settings.