andvm's Posts

indeed, this is the key part: "It is best not to modify these routes manually, and also a best practice to dedicate the selected subnet for the SDDC, by deploying any native services in different subnets within the VPC.  For this reason, make sure to size the VPC sufficiently large to accommodate current and future AWS native workloads that will interact with the SDDC "

@Lalegre - I am wondering if Advanced Cross vCenter vmotion would also work especially if I had to move all workload off from vSAN to FC SAN Storage? If out of current 6x Host cluster I start by removing 2 of them and register them to the new vCenter (with same dvSwitches/LAG/PortGroups pre-setup), would I be able to migrate VMs to new vCenter and then gradually do rest of Hosts/VM's until all Cluster is moved? Basically destination storage and network would remain the same when migrating VM's across vCenter (Source/Destination Hosts will be in same DC and actually same rack) Let me know your thoughts as this could be a way of removing the requirement of having to reconfigure Hosts networking such as moving all connectivity to Standard Switches/PortGroups apart from giving the possibility to migrate VMs to new VCSA in a granular way. Thanks

@Lalegre yes I understand that the VDS can be exported from source vCenter and imported into destination vCenter, just not sure if this changes anything about the migration plan to new vCenter and if it would help me avoid taking the VSS alternative? Let me know if understood this wrong and there is a simple way of just disconnect/unregister the Host from Source vCenter and connect/register to Destination vCenter when the dVS Switch/es and PortGroups have all been exported from Source to Destination vCenter. This would be great if the above can be done when Management/vMotion/vSAN and VM Traffic are all connected via dVS's and Host can simply be re-attached to imported DVS's/PortGroups on Destination vCenter. Even better if there would be no downtime expected to VMs. For example the following link still says to create and move Host to Standard Switch after exporting VDS so not sure how the VSS route can be avoided - https://kb.vmware.com/s/article/1029498  

thanks @Lalegre  So from what I see a good part of it will be about creating Standard Switches (vSS's) for each Service and VM Traffic along with respective portgroups and then moving uplinks, vmkernels and VM Traffic to them. Then on new VCSA import dVS's and PortGroups from backups and revert the above work to move back from vSS's to Distributed Switches (dVS's) Was also hoping there would be some solution that would allow you to move Management plane from one VCSA to a new one without having to move all connectivity via vSS's but seems there isn't.  

ok so there is no NFC without vMotion? (They are needed both even if doing just a clone - no vmotion) Thought they were different and that clone operation uses only NFC. Think it should also be bi-directional as there is import VM functionality that can be launched from destination VCSA.

if there is no solution I guess I need to fall back to enabling retreat mode for this cluster? I wanted to avoid this as cluster is to be decommissioned so the removal of vCLS VMs should happen automatically when all Hosts in a Cluster are placed in MM.    

can you share a screenshot of the respective Reset Rule that would trigger a notification when the Host Connectivity is restored? Otherwise the link is a generic one and does not seem to address my question specifically.

apologies my bad as got another set of Servers which do have ESXi installed on SD. Ultimately I think I got the answer which is that a vSAN Cluster will always need VMFS datastore (shared or per Host to function/follow best practice)    

@IRIX201110141 - Its BOSS-S1 so possible to delete and create 2x virtual disks as per your comment. But in any case this will require the deletion of existing ESXi which is not ideal, so something that should be done first thing prior ESXi install. Actually these are vSAN Ready Nodes so came with ESXi pre-installed now that I remember. I wonder why these do not come pre-partitioned into 2x virtual disks knowing the vSAN requires a VMFS datastore? Bottom line, adding a VMFS datastore via the BOSS Card might be possible but not straightforward in this case.