If these are standalone hosts, they probably aren't sharing the same storage. vCenter is complaining because it can't remediate the host on which it sits because it can't move itself to another host owing to the fact there is (likely) no shared storage. Also, if these hosts are in separate sites and without shared storage, they don't need to be in a cluster to begin with.
My real question relates more about being able to remediate the host that the vcenter appliance is on. I dont want to try and rollup the version to 6.7 U2 plus whatever patches and kill either the server or the vcenter.
Is it just moaning for the sake of it or should I do something first?
As long as your vCenter stays at least as far ahead as the ESXi hosts it manages, you should be fine. But don't try and have a vCenter at, for example, 6.7 U1 and patch your ESXi hosts to 6.7 U2. Follow the interop matrix for the supportability.
thanks I'll give it a go
Sadly this was a complete fail.
The Vcenter was already running 188.8.131.52000 build no. 14070457, but after I performed the remediation and it rebooted the ESXi server that hosts the vcenter appliance is still on 6.7.0 build no. 8169922.
Is there a particular or alternate method that should be followed for this other than kicking it off from vcenter perhaps?
You're going to have to be more descriptive here as I'm not following. You remediated an ESXi host (standalone) on which vCenter was running?
Just shutdown the vCenter and patch the ESXi Host trough commandline
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-6.7.0-20190604001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
esxcli network firewall ruleset set -e false -r httpClient
or by using a CD/ISO.