d3m1g0d's Posts

You can set both Syslog.global.logHost and Syslog.global.logDir -- the logs will be then forwarded to the log server and will be also written to the log directory specified. Both locations will have the same information. If Syslog.global.logDir is empty or points to a scratch partition, you must configure the scratch partition to a location on a persistent storage.

I'm not aware of a specific tool which recreates the log folders. Maybe VMware GSS has a script/program for this purpose. If you want, I can send you a list of the files and directories of /storage/vmware/log along with their permissions as configured on one of my lab VCSAs (would be 7.0 U3 though, but this shouldn't matter).  You would have to create the missing objects in the filesystem manually based on the list or you could create a shell script which assembles the required commands out of this list. Output would look as follows: # find /storage/log/vmware/ -ls 393217 4 drwxr-xr-x 54 root root 4096 Oct 11 00:00 /storage/log/vmware/ 395749 20760 -rw-r----- 1 root root 21254180 Oct 6 00:00 /storage/log/vmware/procstate-20231006.gz 393258 4 drwxr-xr-x 3 root root 4096 Oct 10 15:10 /storage/log/vmware/vmon 393333 288 -rw-r--r-- 1 root root 287280 Sep 11 09:49 /storage/log/vmware/vmon/event-publisher.log 393259 4 drwxr-xr-x 2 vmonapi vmonapi 4096 Sep 11 09:48 /storage/log/vmware/vmon/vapi 393412 3676 -rw-r--r-- 1 vmonapi vmonapi 3757576 Oct 11 13:22 /storage/log/vmware/vmon/vapi/vmon-vapi-provider-0.log 394438 4 -rw------- 1 vmonapi vmonapi 41 Aug 8 20:56 /storage/log/vmware/vmon/vapi/vapi-runtime.log-4.stdout 393411 4 -rw------- 1 vmonapi vmonapi 164 Aug 30 11:59 /storage/log/vmware/vmon/vapi/vapi-runtime.log-0.stderr 394807 4 -rw------- 1 vmonapi vmonapi 41 Aug 10 09:15 /storage/log/vmware/vmon/vapi/vapi-runtime.log-1.stdout 394303 4 -rw------- 1 vmonapi vmonapi 164 Sep 11 09:48 /storage/log/vmware/vmon/vapi/vapi-runtime.log.stderr  

Have you managed to get services started by modifying permissions on files and folders in the filesystem? Is it related to the log folders? If you really want to manually adjust files and folders in the VCSA: You could deploy another VCSA with the same version as a "blueprint", and modify permissions on the required files and folders in the broken VCSA as configured in the newly deployed appliance. But I would rather recommend redeploying the VCSA and restore a previous working configuration from backup to have a clean system.

Regarding the error:  Caused by: org.apache.http.conn.HttpHostConnectException: Connect to localhost:1080 [localhost/127.0.0.1] failed: Connection refused (Connection refused) Seems that the Envoy proxy is not running/listening on port 1080. You can check it on the VCSA: service-control --status envoy rhttpproxy and specifically: netstat -anp | grep tcp.*LISTEN.*envoy Have you tried to start/restart it the envoy service? service-control --restart envoy Or restart all services? service-control --stop --all && service-control --start --all Is there anything meaningful in the Envoy logs in the directory /var/log/vmware/envoy? In the rhttpproxy logs in /var/log/vmware/rhttpproxy? Also check /etc/hosts for any errors (see https://kb.vmware.com/s/article/59476).

You can set some advanced options to customise the behavior of the vSphere HA cluster:  https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-availability/GUID-E0161CB5-BD3F-425F-A7E0-BF83B005FECA.html https://kb.vmware.com/s/article/2033250 (up to vSphere 7) In general I would not recommend to change the default values.

Please check if the vNIC of the VM is actually connected to the port group.  If the vNIC is not connected, then the port will not become active. You can achieve this by right-clicking th virtual machine in the inventory and select Edit Settings. On the Virtual Hardware tab, scroll down to the Network Adapter and select the option "Connected" and/or "Connect at power on". Then click Save.

This is really not an ideal setup. Nevertheless, in this case you could upgrade/patch your ESXi host directly from the host using esxcli. Without being able to leverage vMotion the upgrade would of course require a downtime of all VMs residing on that ESXi host.  See the official docs for more information: https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-esxi-upgrade/GUID-02D172FC-BB21-4087-BA27-5B0D4AE8EED0.html

vTPM and Native Key Provider are available with all license levels of vSphere. But you need vSphere Enterprise Plus if you want to use VM Encryption. See here: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsphere/vmware-vsphere-pricing-whitepaper.pdf  (interestingly, NKP is not selected in this document for vSphere+ Standard for whatever reason, but that's another story I guess)

From the attached screenshot, I can see that Aria Suite Lifecycle seems to configure an Orchestrator cluster. Did you set up a load balancer to distribute traffic among the Orchestrator instances before deploying Orchestrator? This has to be done manually outside of Aria Suite Lifecycle. Then you should add the load balancer VIP to the certificate before performing the lifecycle operation.

Not much information about the environment has been provided, so it is a bit of educated guessing now. Is this occurring with VMs running from a flat VMDK on vSAN?  Then the following KB article may be helpful: https://kb.vmware.com/s/article/50121428  

Have you already solved this? If not, a few ideas to consider: As it seems that you have already tried to delete/restart the ebs-app pods, did you find some relevant messages in the log files (e.g. ebs-app.log, deploy.log, ...)? Is it the Aria Automation ingress SSL certificate, which has been expired? Have you renewed it since then? If not renewed yet, maybe it is worth trying to renew it e.g. by using Aria Platform Lifecycle or using vracli on the Aria Automation appliance directly (which includes a re-deployment of the prelude services).

Yeah correct, nice read! You can overcome the OOTB limitation of cloudConfig being just user data using cloud-init's VMware datasource with guestinfo transport by leveraging am Extensibility Orchestrator workflow instead on relying on the default OVF datasource with the clunky ISO transport. This raises the question if this is really easier than just using write_files and run_cmd within the cloudConfig property of a Cloud Template (I understood that it was a requirement of V00Z). But if you want to use cloud-init's network config, then this is the way... Anyway, it would be really nice if the VMware datasource would make it into Aria Automation's OOTB functionality to be able to take advantage of it directly.

Afaik this cannot be achieved using the cloudConfig property in Aria Automation, as it is only user-data. See the statement in the cloud-init documentation link you've provided: "User data cannot change an instance’s network configuration. In the absence of network configuration in any of the above sources, cloud-init will write out a network configuration that will issue a DHCP request on a “first” network interface."

Afaik you cannot do this with the Move-VM cmdlet. It only accepts a single datastore as destination. You should be able to do it using the RelocateVM_Task of the VirtualMachine SDK object. You would need to build a VMware.Vim.VirtualMachineRelocateSpec object for the virtual machines config files specifying the destination datastore MoRef. Then add a VMware.Vim.VirtualMachineRelocateSpecDiskLocator object for each VMDK specifying its DiskID and Datastore MoRef from the destination.