RealQuiet's Posts

SDDC is on 4.5.2 and I have generated the SoS logs, which allowed me to query the logs when using the SDDC Manager UI. I I am looking for the log name that will store login successes and failures when using SSH or the console access using the local vcf and/or root account. 

Did you check your proxy settings? Make sure they are not cleared out and/or that you have the correct entries for when it should bypass the proxy.    /etc/sysconfig/proxy   NO_PROXY="localhost, 127.0.0.1,<vcsa_fqdn>, <vcsa_ip>,<sddc_fqdn>,<sddc_ip> "

This turned out to be a valid way to create the workload domain using vmnic0 and 2 instead of 0 and 1: "vmNics": [      {           "id": "vmnic0",           "vdsName": "VDS01",      },      {           "id": "vmnic2",           "vdsName": "VDS01",      } ] I am not sure what the moveToNvds does and how it is used if I want to create the VM workload vDS during the bring up. I am assuming that the NSX-T configurations will automatically attach to VDS01 because it is declared with the "isUsedByNsxt". 

Ok, if I am reading it correctly, then I would need something akin to this:   "vdsSpecs": [ {      "isUsedByNsxt": true,      "name": "VDS01",      "portGroupSpecs": [ {                "name": "VDS01-pg-mgmt",                "transportType": "MANAGEMENT"           },           {                "name": "VDS01-pg-vsan",                "transportType": "VSAN"           },           {                "name": "VDS01-pg-vmotion",                "transportType": "VMOTION"           } ]      } ]   At which point the  ""isUsedByNsxt": true," flag would place the NSX-T configuration on this vDS as well. VDS01 would carry vMotion, vSAN, ESXI Management, and NSX-T. For the hostNetworkSpec, can it IGNORE vmnics or does each one have to be assigned a vDS and port group configuration?  Configuration 1: vmnic1 and vmnic3 to carry VM Workloads "vmNics": [      {           "id": "vmnic0",           "vdsName": "VDS01",           "moveToNvds": true      },      {           "id": "vmnic1",           "vdsName": "VDS02",           "moveToNvds": false      },      {           "id": "vmnic2",           "vdsName": "VDS01",           "moveToNvds": true      },      {           "id": "vmnic3",           "vdsName": "VDS02",           "moveToNvds": false      } ]   Configuration 2: Can we bypass configuring vmnic1 and vmnic3 and configure the vDS later? "vmNics": [      {           "id": "vmnic0",           "vdsName": "VDS01",           "moveToNvds": true      },      {           "id": "vmnic2",           "vdsName": "VDS01",           "moveToNvds": true      } ]

Tried the dis-join and rejoin. Did it using the GUI then shell. Same result. Went through the hassle and set up the LDAP and it works. No victory for me, now I need to document this as it is different from all the other VCSAs in the environment. So it works, I am just not happy about the implementation. The answer is if user groups do not work using AD Integration then use LDAP.

During my research I also ran across forum postings saying that using LDAP would work. It is just frustrating because we have 5 other VCSAs that do no have this problem. This particular VCSA resides in the same subnet as the DC that it would be communicating with, so there are no firewalls causing issues. If I cannot find a solution by Tuesday, then I will try the LDAP solution. Not ideal, as it would be configured differently than the rest of the environment.

Yes it is an AF-8 sizing. I am actually gathering IO data to see what our needs our. Gathering the IO data this week. Working on a data capture for at least a week. We have a follow the sun model, so workloads vary depending on the shift. Thank you for your link, it accounts for changes to SSD endurance and now I am seeing errors in my calculations for the caching tier change. I may revert it back to 400GB... but I do like the endurance and ability of a larger caching drive to hold objects longer before having to write them to the capacity tier. I was using older information from: https://cormachogan.com/2015/05/19/vsan-6-0-part-10-10-cache-recommendation-for-af-vsan/

I actually pushed up to 800GB, they started with 400GB and I just thought I could push performance more if it had the 600GB to leave objects in as long as possible. Personally I feel that losing a disk group because a cache drive wears out is a little much. Especially when I consider that if it wore out, and vSAN is doing this evenly, then the remaining cache tier drives may follow. If anything, I want the capacity drives to wear out first and, if the system is still around, then the caching tier. I spoke with the vendor about my SATA concerns, and they still recommended SATA over SAS for the capacity tier. They put me at ease over that, of course I still want to hear from other's experiences Anyone have VDI experience with SSD SAS caching tier and SSD SATA capacity tier? Your input would be appreciated.

I agree that CPU resources are not often highly utilized. The issue is that CPU Ready time increases and performance is impacted by the process delay. The proposed configuration is almost identical in core count, so the hope is that CPU Ready time does not increase. I am concerned that there is some nuance in how resources are handled with two socket hosts vs one socket hosts that will significantly increase CPU Ready time even when core counts are nearly identical.