Lalegre's Accepted Solutions

Hello @KoolSach, What about connectivity? Can you tried connecting from the appliance using telnet or nc over port 443? Also, you could retry the connection and check here for errors: /opt/vmware/vcloud-director/logs/vcloud-container-debug.log

@aniros, So the point is the following, if you decide to go with SQL Always On using AG (Availability Groups) you do not need any type of storage access from the Guest OS at the same time as replication happens between the Databases Individually on each of the nodes. However, if you decide to go with SQL Always On with FCI (Windows Failover Clustering) you will need a volume that is accessible at the same time from both SQL Servers as the Databases are shared between them, this could be by using SCSI Bus Sharing, iSCSI, RDMs, etc)  

@hamidsattarrana, As per your previous thread, you mentioned the following: xeon CPU E5 2680 If that is your CPU, then the maximum level is Sandy Bridge and no Broadwell. It is also displayed here: https://ark.intel.com/content/www/es/es/ark/products/64583/intel-xeon-processor-e52680-20m-cache-2-70-ghz-8-00-gts-intel-qpi.html. Unless you are not sharing with us the proper version (v2, v3, v4) Also, if you want to enable into a cluster you can do it of course but for the VMs that are running on the Gold host, you will need to power them off as the vMotion will not work as they are using CPU capabilities not available on the E5-2680. If you decide to go with the cluster, you need to do the following: Create an empty cluster and enable EVC Sandy Bridge Add the E5-2680 host to the cluster (No downtime is required for the VMs running in it) Power-off the VMs on the Gold ESXi and vMotion them to the Xeon ESXi Once you finish migrating all the VMs, add the Gold ESXi into the cluster. That way the cluster will pick up the EVC level and force the compatibility.  

@omadmin, Cloning an ESXI is not a supported method at all, what you should do is backing up the configuration and restore in case you need it: https://kb.vmware.com/s/article/2042141.  Also, if you are trying to do this for configuring the same on the new host, I recommend you to use Host Profiles if you have the licenses to do so.

@jwmb224, As mentioned above, when the CPU gets certified by VMware, it will show in the HCL. Note aside, the W-3100 previous gen is supported for vSphere 8 so I believe is a matter of time till W-3400 is listed there.

@nblr06, Yes, of course, you could achieve this by creating custom alarms, as the metrics to be used will be the same as in the original alarms. You could use different names, modify the threshold a little bit, and even put a well-detailed description.

@usmabison, I was reading a little bit more and testing myself, and it seems that you cannot simply redirect back to /tmp and expect the /scratch to be re-created (Do not know why). Try the following: 1. mkdir /tmp/scratch 2. Update ScratchConfig.CurrentScratchLocation with /tmp/scratch 3. reboot Let me know how it goes.  

@Gimbo58  The only supported way of shrinking a VMDK is by using VMware Converter Standalone and selecting a different VMDK Size, you cannot use any other method. All detailed here: https://kb.vmware.com/s/article/1002019

@PhilippJe, One thing first to try is: Logoff session Clear cookies from the browser Login the session  Now, if that does not solve your issue, try to click the search again to generate new fresh logs, connect to vCenter over SSH and get this log attached here: /var/log/vmware/vsphere-ui/logs/vsphere_client_virgo.log  

@csitsoftware, I believe this is happening because your root password on vCenter is expired. Tried to reset the password by following this procedure and try again: https://kb.vmware.com/s/article/2147144

@520192, Go with Terraform for sure, the proprietary language they have known as HCL is super easy to understand and it will provide you the capabilities of "dry-running" the configurations before deploying.

Hello @jerry5, I believe the issues you are facing are two: vSwitch and Portgroup: One the way you are setting the vSwitch is letting it choose one vmnic as Active (by default) and because of your restart, it could be possible that the vmnic2 took that position. Even if you have the 2 vmnic as Active, that is not the proper configuraiton. IP Assignment: Make sure that not both of the IP ranges that you have are giving IPs with the Gateway IP on the configuration because if that is the case, you will end having duplicate default routes and the Ubuntu box will not know to where send the traffic. If In understood well, the scenario you are trying to achieve is to have an IP from ranges 192.168.1.x for the management, I am assuming that this network is purely L2 and you do not need to access other subnets from this IP. What you should ensure is that the default gateway is only from network 172.21.6.x Solutions to this issue: vSwitch and Portgroup: Create a separate vSwitch and move the vmnic for Internet to there. Create a portgroup on that vSwitch. Connect the second vNIC of the Ubuntu box to that portgroup. IP Assignment: Only if you have the duplicate gateway IP issue, make sure only the DHCP from the Internet subnet gives you the gateway. Let me know how it goes. Regards!  

@sweehan. Yeah in that case it will work for sure, you can do the movement without any issues. Just power-off the servers. Check the resolution section in this KB for reference: https://kb.vmware.com/s/article/79910

Oh okay, so that means the contents are still there, which is good but you need to recreate the descriptor file. I advise you to follow the next KB that details properly the step by step on how to recreate the descriptor file which will point to the disk content (flat-vmdk) https://kb.vmware.com/s/article/1002511 PS: Note that on point 3 you probably do not have the .vmx (I am assuming here) with the details of the SCSI adapter used but the default one is LSI Logic SAS so on the new empty VM you can start with the same. Read carefully, start one point by one and in case it gets complex you can even reach me out on the messages.