Hi,
Is there anything that can be investigated to prevent such logs being missed to be sent to the syslog server?
I see this message on different hosts (6.5 and 6.7) and am wondering if I can do anything to find the cause?
Should ESXI's be left with logging level at Informational (Default) or this generates excessive logs/traffic?
What free Syslog Server do you use or recommend?
Thanks
Hi Luc! Thanks for responding.
If I merely do a Start-VM at the end of the script, the OS customization does run but the VM is neither renamed nor re-IP'ed as part of the customization process.
I am also not prompted to enter this information after I run the script.
I am looking for a way to specify a computer name and IP address in the script itself but I have not been able to figure this out.
$vmname = Get-VM -Name MyVM
$custspec = Get-OSCustomizationSpec -Name 'PDC_Windows'
Get-VM -Name $vmname | Set-VM -OSCustomizationSpec $custspec -ComputerName 'NewName' -IpAddress '192168.1.10'<< Trying to do something like this.
Can you please help me understand more about this because i have no idea what this means???????
Thank you for the suggestion. I ended up just going with a much shorter timer. I basically have it pause execution for only 4 hour increments, and then check to see if we are past the desired date, and resume execution when we get there. It's a lot of pause/resume workflow for what I wanted, but it seems to be working well so far. The benefit is that I don't have to have an active token like with a sleep for the entire duration, but it seems like it doesn't lose track of the token with a 4 hour wait timer, at least so far. I didn't want to externalize the process, because its basically the entirety of the workflow, there's a lot more steps than just destroy the VM - remove from AD, remove from DNS, remove from monitoring, etc. But the explanation of the rabbitmq queue makes sense if thats not clustered.
there are tens of servers pointing to the same syslog server so will check basics CPU/RAM/Network utilization
If in meantime anyone can offer other insights as to what logging level you set the ESXi's and syslog server you use that would be great
I have a template with server 2019.
I have created some servers from template and used my 2019 customization file.
But servers have not been customized.
In customization file I have not inserted any license key, because I still waiting to get one.
The template is also not licensed.
Could that be the reason?
My 2016 templates/customizaion is working fine.
Hello
PowerCLI is user friendly - but to use it I have to log on to a Windows VM - windows not so reliable for a "cron" job, etc.
You can just use the task scheduler on windows, and you can also install powercli on linux, and do a cron there. I really suggest not doing a cron directly on the appliance or the esxi hosts.
Ok, gotcha.
Changing the hostname inside the guest OS is afaik not available through OSCustimizationSpec directly.
You could use the GuiRunonce parameter if the guest OS is Windows based.
Otherwise, you will have to fall back on the Invoke-VMScript cmdlet (after the customisation and the power on). Also note that this requires VMware Tools to be running.
For the IP address you have to configure your OSCustomizationSpec via the Get- and Set-OSCustomizationNicMapping cmdlet
There is a series of blog posts on the subject on the PowerCLI Blog.
This should provide you with some detailed info
Thanks for helpful reply.
As far as logging levels go, stay at defaults unless troubleshooting. As for syslog servers, vRealize Log Insight, Splunk, and SolarWinds are what I most often see.
That seems like a much better option! Thanks so much for sharing Bob
-Mike
When I create a cluster, I am getting following error.
Deployment VM state is showing as follows
SSH to the master VM and check the logs in
/var/vcap/sys/log/pks-nsx-t-prepare-master-vm/pre-start.stderr.log
time="2020-03-06T16:29:37Z" level=warning msg="NSX-T communication config: server tls authentication is disabled"
time="2020-03-06T16:29:44Z" level=warning msg="NSX-T communication config: server tls authentication is disabled"
Error: timeout: client certificate is not working after 60 seconds
/var/vcap/sys/log/pks-nsx-t-prepare-master-vm/pre-start.stdout.log
Registering client certificate
dc0a43bf-685a-42f1-b186-e41c1f727554
Registration of client certificate is successful
Checking if client certificate is ready to be used
timeout: client certificate is not working after 60 seconds
If I run the command /var/vcap/jobs/pks-nsx-t-prepare-master-vm/bin/pre-start ...it is work fine...even it is waiting for some time.
Node IP block and Management IP block are routable.
Everything behind NSX-T (2.5.1)
PKS management console v1.6.1-rev.1
Thanks
Ok, I assume this is a Horizon related issue.
But is this my question has a solution ?
"can I create cluster and put new hosts in that and use vSAN datastore from another cluster in same datacenter ?"
If it has, would tell me how to do it ?
mj19922007, A host can only access the vsanDatastore of the vSAN cluster it is part of - a host can only be a member of one vSphere/vSAN cluster.
Whether additional hosts added are providing storage to the cluster or not is irrelevant - they are still members of the cluster and should be able to access the vsanDatastore (but only this clusters vsanDatastore, not those belonging to other clusters).
Bob
I have not specifically run into this one, but a couple of guesses as to the cause: 1) ESXi host has a state issue, possibly with hyperbus transport. Try a rolling reboot. 2) possible consistency issue with the managers. Can check the proton log file during cluster creation to see what is being logged.
I'd probably recommend opening an SR regardless because there is a lot of complexity here and troubleshooting can be difficult.
In early 7.*, (probably 7.3-7.5), I had to set the value to 0 because post provisioning when Chef runs to install an application that writes files to the new drives, it failed because the new drives were not accessible. The drives were NOT initialized and ready for use despite having the Guest Agent active in the VM and filling out the drive letter and size on the vRA form. If I remove this setting, I have to either script the formatting and initialization or manually do it once the vm is provisioned. Windows OS is configured NOT to automate the processing of newly added drives in this manner, so I don't know how the Guest Agent bypasses that without this setting. I have not tried it in 7.6.
Who in VMware thought it was a good idea to only support SMB1 in 2019?! Why bother even releasing the functionality if your only going to use a decrepit protocol that everyone else has abandoned at this point, even Microsoft.
That's just it. The location at C:\ProgramData\....., the Startup folder is empty; and within %APPDATA%\Microsoft, it is empty pastAPPDATA%\Microsoft\Windows (There is no Startup folder).
Mario_Juarez and rwamps,
After doing some testing and validation with Mario_Juarez and our R&D team, it turned out that the device in question (Latitude E5401) did not support the Wake-on-LAN "BIOS Attribute" setting of "LAN or WLAN" was not supported by the device, therefore the profile failed to install. Feedback on seeding the latest version of the Dell Command | Monitor client and improving the return of why the profile failed to install back to the console has been passed along to R&D.
rwamps - let me provide a few tips to get this working for you as well. Ensure that you currently do not have a BIOS password set, if so, clear the password/set it to blank. Ensure the device supports all attempted configurations that are set in the BIOS profile. If you are unsure, I will tell you how to verbose the logs to see what is failing.
$adminPwd = ""
$attribute = "AdminPwd"
$value = ""
Get-CimInstance -Namespace root\dcim\sysman -ClassName DCIM_BIOSService | Invoke-CimMethod -MethodName SetBIOSAttributes -Arguments @{AttributeName=@($attribute);AttributeValue=@($value);AuthorizationToken=$adminPwd}
I will be updating the Integrating with Dell Client Command Suite: VMware Workspace ONE Operational Tutorial | VMware on Tech Zone soon with some of this information and added warnings to ensure System and BIOS attributes are supported on the managed Dell devices.
Respectfully,
Josue