Daniel Micanek virtual Blog – Like normal Dan, but virtual.
SAP HANA on vSphere 8 with 4th Gen Intel® Xeon® Scalable processors (Sapphire Rapids) gained support last year. Initially, deploying SAP HANA as ‘half-socket’ sized VMs wasn’t supported by SAP, limiting deployment to a maximum of 2 SAP HANA production VMs on a 2-socket Sapphire Rapids server. […]
On VMware CMTY Podcast #686, WE April 3, Gareth Edwards, a key Community member and Solution Engineer at VMware Broadcom, explores the innovative Holodeck project—a fully automated lab with all the bells and whistles. Whether you’re a seasoned pro or new to home lab setups, this podcast offers […]
ESXi supports dual stack networking (IPv4 and IPv6) by default, however users can also configure just IPv4 or IPv6, which requires a system reboot for the changes to go into effect. Recently, I received a question from a colleague asking if there was a way to disable IPv6 during ESXi Kickstart […]
PowerCLI automation for VMware Private AI Foundation with NVIDIA (PAIF-N)
With the release of VMware Cloud Foundation (VCF) 5.1.1, customers can now take advantage of the new VMware Private AI Foundation with NVIDIA (PAIF-N) solution, providing an optimized and validated platform by NVIDIA for running modern AL/ML workloads on VCF. To learn more about the PAIF-N solution for VCF, there is a comprehensive PAIF-N Guide […]
Project Cypress integrates generative AI into VMware’s lateral security solution, acting as a co-pilot when investigating threats.
A few weeks back, I had a request from one of our Technical Adoption Managers (TAM) that their customer wanted to create a custom ESXi VIB that could be used with vSphere Lifecycle Manager (vLCM) and would only require the ESXi host to reboot as part of the remediation. This might sound like […]
ESXi Scripted Installation (Kickstart) has been my go-to method for achieving zero-touch provisioning of ESXi hosts at scale, which I had started using back in the ESX 2.5 days when I was a customer! Having worked at some very larger enterprises, I got the opportunity to experience and manage […]
I’ve had this question twice in about a week, which means that it is time to write a quick post. How do you stop vCLS VMs from running on a vSphere HA Failover Host? For those who don’t know, a vSphere HA Failover Host is a host which is used when a failure has occurred […]
After deploying a new VMware Cloud Foundation (VCF) Workload Domain using the VCF Holodeck Toolkit, which leverages Nested ESXi, I noticed the vSphere Cluster Services (vCLS) VMs kept failing to power on and threw the following error message: No host is compatible with the virtual machine I […]
This blog post delves into the configuration of NSX components for remote Syslog transfer, a critical step in centralizing log management and enhancing network visibility.
By default, NSX components store logs locally, which can be accessed in privileged mode. These logs are crucial for troubleshooting and auditing purposes, offering insights into the system’s operations and potential issues. The default storage location for these logs is the /var/log directory. Here’s a quick overview of the log files and their locations for various NSX components:
/var/log/syslog, /var/log/proton/nsxapi.log, and /var/log/nsx-audit.log/var/log/syslog./var/log/cloudnet/nsx-ccp.log./var/log/nsx-syslog.log.To leverage the full potential of logging, configuring NSX components to transfer logs to a remote Syslog server is advisable. This allows for centralized log management, making it easier to monitor and analyze the logs from various components in a single location. Here are the commands to configure logging to a remote Syslog server for different NSX components:
set logging-server <IP Address/fqdn:Port> proto udp level infoget logging-serversset logging-server <IP Address/fqdn:Port> proto tcp level infoget logging-serversThese commands should be executed with the appropriate IP address, fully qualified domain name (FQDN), and port of your Syslog server, alongside the protocol and log level specified. The choice between TCP and UDP protocols depends on your requirements for log delivery confirmation and network overhead. Generally, TCP is used when acknowledgment of log receipt is required, while UDP is used for lower network overhead.