Category: BLOG

My Own

VMUG Czech Republic: Deep Dive into VCF Networking, Kubernetes Integration, and Cybersecurity

On an inspiring day at Greenpoint Prague, we gathered for the VMware User Group (VMUG) Czech Republic event, which I had the pleasure of organizing alongside Josef Zach. The venue buzzed with energy as we eagerly anticipated a day filled with insightful sessions and vibrant networking.

The day started strong with Karel Novak‘s compelling session, “VCF Multi-Location Networking.” Karel captivated us all by diving deep into the complexities of VMware Cloud Foundation, especially advanced networking across multiple locations, providing valuable insights to manage complex infrastructures effectively.

Next up, Katarina Brookfield delivered an excellent presentation, “vSphere Supervisor – Unlocking Cloud Experience with Kubernetes.” She skillfully showed how vSphere bridges the gap between traditional IT and modern cloud-native applications, leaving us with plenty to think about in terms of operational agility and Kubernetes integration.

Boris Mittelmann then brought cybersecurity front and center with his essential session, “Veeam on MITRE ATT&CK v17 – Cyber Security and Recovery for ESXi.” Boris offered actionable tips and real-world insights on securing virtual environments, highlighting the importance of cyber resilience and preparedness.

In the afternoon, Karel Rudišar provided valuable perspectives in his talk, “Traditional and DevOps Approach and Automation in VCF.” He effectively illustrated the advantages of combining traditional IT practices with DevOps methodologies to streamline automation within VMware Cloud Foundation.

The critical topic of ransomware was expertly covered by František Ferenčík and Marek Ištok, whose session, “Ransomware Recovery for VCF,” offered practical strategies to mitigate ransomware threats and ensure robust recovery methods, essential for maintaining a secure VMware Cloud Foundation environment.

Petr Rada contributed further with insights into VMware Cloud Foundation, helping to deepen our collective understanding of key operational practices.

We wrapped up the informative sessions with an engaging roundtable discussion featuring VMUG Leaders and all session speakers. This interactive segment allowed us to share experiences and exchange valuable ideas.

Adding excitement to the event was our raffle, where lucky attendees won two exclusive VMUGCZ t-shirts, five handy multi-use tags, a Bluetooth speaker, a LiveFire water bottle, and a special 50% discount voucher for VMware training.

The day concluded on a high note with a fantastic grill featuring delicious meats, vegetables, sausages, complemented by refreshing beer and great company during our social networking session. It was the perfect end to a rewarding day of learning and community building.

A heartfelt thanks to our sponsors VEEAM, TD SYNNEX , Broadcom and all speakers, attendees, and my co-organizer Josef Zach for making the VMUG Czech Republic event such a memorable success. I’m already looking forward to our next meetup!

VMUG Connect 2025 Recap: From Brewery Chats to Certification Success!

Just got back from VMUG Connect 2025 in Saint Louis, and what an incredible experience it was! From the moment I landed, the energy was buzzing, and kicking off the event at the pre-connect gathering in a Budweiser brewery set the perfect casual tone to network and catch up with friends and peers from around the globe.


The keynotes were truly inspiring. Pablos Holman, the hacker, inventor, and investor, delivered a fascinating talk about innovation, challenging us to rethink possibilities.

Meanwhile, Frank Denneman’s keynote on AI’s evolving role in technology had me scribbling down notes like crazy—exciting stuff ahead!


My favorite session had to be the PowerCLI Deep Dive. As someone who loves scripting and automation, it was packed with practical insights that I can’t wait to implement back at work.

Other standout sessions included:

  • The Art of Public Speaking
  • Technical Deep Dive into VCF Integration
  • Building Private Cloud with VCF
  • Simple Kubernetes
  • VMware Cloud Foundation – Edge
  • Hands-on Labs featuring VMware Live Recovery, Kubernetes, and NSX Networking
  • Corey Romero’s Jedi-level tips on how to become a vExpert

One session that particularly resonated with me was the HomeLab workshop. Being passionate about HomeLabs, this session provided fantastic ideas and tips on building efficient, powerful, and cost-effective lab environments at home. The discussions around hardware choices, networking setups, and virtualization best practices were incredibly valuable and left me inspired to upgrade and refine my own setup.

I also attended the big session with Weiguo He, “A Look Inside the Future of VMware Cloud Foundation“, which offered exciting insights into upcoming developments.

Exploring the vendor hall was another highlight. Interacting directly with solution providers offered valuable face-to-face discussions, giving insights into some great tools that I’ll definitely look into integrating into my workflow.

The event wrapped up with a fantastic fireside chat featuring Hock Tan and Chris McCain, offering thoughtful insights and discussions on the future direction of VMware.


One personal highlight was passing my VCP-VCF Administration exam during the event—what better way to celebrate than surrounded by the vibrant VMUG community?



Already looking forward to our VMUGCZ event on May 29… Stay tuned!

MyVMUG #VMUGConnect2025 #TechCommunity

VMware next event: https://www.vmware.com/explore/us?utm_source=BCMCMTY&utm_medium=social&utm_campaign=vmx25

My VMUG Leader Summit 2025 Experience in Saint Louis!

I recently had the fantastic opportunity to travel from the Czech Republic to Saint Louis, USA, for the 2025 VMUG Leader Summit. As a proud Czech Republic VMUG Leader, this journey was particularly exciting for me—filled with long flights, amazing people, and tons of great insights.

My trip began in Prague, with stopovers in Amsterdam and Minneapolis before finally landing in Saint Louis. Traveling halfway across the globe was an adventure itself, and despite the long hours, the excitement of attending the Summit made it more than worth it.

The Summit was held at the Hilton at the Ballpark, right in the heart of Saint Louis, which made it convenient to explore and attend the planned events. From the moment I arrived, it was clear that this was going to be a special experience. VMUG had everything meticulously organized—from airport transportation (thanks to handy Uber vouchers) to welcoming receptions at iconic local spot like the Cardinals Stadium.

The two days of the event were packed with insightful sessions, networking opportunities, and interactive workshops. The Workshops were highlights for me, providing practical ideas and tools that I’m excited to implement back home. It was incredibly inspiring to see VMUG leaders from six continents sharing their experiences, challenges, and visions for the future.

A standout part of the Summit was reconnecting with old friends and making new ones from all over the world. The community spirit was genuinely heartwarming. It reminded me once again why I’m passionate about VMUG—it’s more than just technology; it’s about the people and the impact we create together.

Another exciting part of the Summit was celebrating the outstanding achievements of our peers at the VMUG Service Awards. Congratulations again to all the winners:

Stephen Wagner (Calgary VMUG)- President’s Award
Alejandro Padilla (Ecuador VMUG)- President’s Award
Jens Klasen (Kaiserslautern VMUG)- Innovation in Leadership Award
Sweta Sharma (Bangalore VMUG)- Innovation in Leadership Award
Pedro Acosta (Myrtle Beach/Charlotte/Columbia VMUG)- Collaboration Excellence Award
Barcelona VMUG– Collaboration Excellence Award
Galicia VMUG- Collaboration Excellence Award
Vali Cyber- Partnership Award
Franky Barragan– Outstanding VMware Support Award
Joe Graziano (Philidelphia VMUG)- Newcomer Award

Plus, the city itself was vibrant, welcoming, and full of history and entertainment, making our stay even more enjoyable.


I returned home energized, motivated, and loaded with great ideas and insights.


Thanks to everyone who made this experience unforgettable. Until next time, keep connecting and growing! Cheers!

#VMUGLeaderSummit2025

VMware next event: https://www.vmware.com/explore/us?utm_source=BCMCMTY&utm_medium=social&utm_campaign=vmx25

How to Suppress ESXi Shell Warnings with PowerCLI

If you’re managing VMware environments, you might occasionally run into persistent shell warning alerts in your ESXi hosts. Thankfully, you can quickly find and suppress these warnings with a bit of PowerCLI magic.

Check for ESXi Hosts with Shell Warnings

Show the actual advanced settings on all hosts. Log into vCenter using PowerCLI and run this command: 

 Get-VMHost | Get-AdvancedSetting | Where-Object { $_.type -eq 'VMHost' -and $_.name -eq 'UserVars.SuppressShellWarning' } | Format-Table entity, name, value

Command output:

Entity                Name                          Value
------                ----                          -----
...
fs-vsan-04.int.dc5.cz UserVars.SuppressShellWarning     1
fs-vsan-05.int.dc5.cz UserVars.SuppressShellWarning     0
...


Check which ESXi hosts haven’t suppressed the shell warning (default). Then run the following command:

 Get-VMHost | Get-AdvancedSetting | Where-Object { $_.type -eq 'VMHost' -and $_.name -eq 'UserVars.SuppressShellWarning' -and $_.value -ne 1 } | Format-Table entity, name, value

This command outputs a table listing all hosts where the shell warning hasn’t been suppressed—it remains visible in the GUI.

Command output:

Entity                Name                          Value
------                ----                          -----
fs-vsan-05.int.dc5.cz UserVars.SuppressShellWarning     0

Suppress the Shell Warnings

Now, to suppress the shell warnings on selected ESXi hosts, run this simple command:

$esxi="fs-vsan-05.int.dc5.cz"
Get-VMHost $esxi| Get-AdvancedSetting | Where-Object { $_.type -eq 'VMHost' -and $_.name -eq 'UserVars.SuppressShellWarning' -and $_.value -ne 1 } | Set-AdvancedSetting -Value 1 -Confirm:$false | Format-Table entity, name, value

This command immediately disables the shell warnings on selected hosts. No more alerts in GUI!

Command output:

Entity                Name                          Value
------                ----                          -----
fs-vsan-05.int.dc5.cz UserVars.SuppressShellWarning     1

Why (Not) Suppress Shell Warnings?

It’s important to note that suppressing shell warnings is only advisable in lab or non-production environments. In production environments, shell warnings provide valuable security reminders. Always keep shell warnings enabled to maintain security awareness unless you’re working in a controlled test environment.

Happy scripting!

How to Quickly Check/Backup ESXi Host TPM Encryption Recovery Key Using PowerCLI

Managing encryption across multiple ESXi hosts can be a bit of a hassle. But don’t worry. I’ve got a simple PowerCLI script that’ll save you time and headaches by quickly retrieving encryption status and recovery keys from your VMware environment.

Why Do You Need This?

Ensuring your ESXi hosts are correctly encrypted is essential for security. Regular checks help prevent surprises later, especially during troubleshooting or audits.

Getting Started

First, make sure you’re connected to your vCenter:

Connect-VIServer -Server

Replace with your vCenter IP or FQDN.

The Script Breakdown

Here’s a quick rundown of the PowerCLI script to verify encryption settings across all ESXi hosts and who Recovery key for each ESXi host. (link to GitHub repository and file tpm_recovery_key_backup.ps1):

# Connect to your vCenter server (if not already connected)
# Connect-VIServer -Server <VCENTER_IP_OR_FQDN>

$esxis  = get-vmhost | Sort-Object

foreach ($esx in $esxis) {
    $key= @()
    $enc = @()
    if ($esx.ConnectionState -ne "Connected" -and $esx.ConnectionState -ne "Maintenance") {
        Write-Host ""
        Write-Host "================================================================================" -ForegroundColor Yellow
        Write-Host "🚫 SKIPPED HOST" -ForegroundColor Yellow
        Write-Host "Host                : $($esx.Name)" -ForegroundColor DarkYellow
        Write-Host "Reason              : Not powered on or disconnected." -ForegroundColor DarkYellow
        Write-Host "================================================================================" -ForegroundColor Yellow
        Write-Host ""
        continue
    }
    $esxcli = Get-EsxCli -VMHost $esx -V2
    try {
        $key = $esxcli.system.settings.encryption.recovery.list.Invoke()
        $enc =  $esxcli.system.settings.encryption.get.Invoke()

        Write-Host "================================================================================" -ForegroundColor DarkCyan
        Write-Host "🔹 ESXi Host        : $($esx.Name)" -ForegroundColor Cyan
        Write-Host "🔐 Recovery ID      : $($key.RecoveryID)" -ForegroundColor Green
        Write-Host "🗝️  Recovery Key     : $($key.Key)" -ForegroundColor Yellow
        Write-Host "🔒 Encryption Mode  : $($enc.Mode)" -ForegroundColor Magenta
        Write-Host "================================================================================" -ForegroundColor DarkCyan
        Write-Host ""
    }
    catch {
        Write-Host ""
        Write-Host "================================================================================" -ForegroundColor DarkGray
        Write-Host "❌ ERROR for host    : $($esx.Name)" -ForegroundColor Red
        Write-Host "⚠️  Failed to get encryption key for $($esx.Name) ."
        Write-Host "🧨 Error details     : $_"
        Write-Host "================================================================================" -ForegroundColor DarkGray
        Write-Host ""
    }
}

What the Script Does

  • Connects to each ESXi host.
  • Checks if the host is Connected or in Maintenance mode.
  • Retrieves the Encryption Recovery ID and Key.
  • Shows the current encryption mode.
  • Gracefully handles hosts that are offline or disconnected, clearly indicating skipped or problematic hosts.

Output

Connected hosts or in Maintenance with Encryption keys

Powered off or disconnected hosts – Skipped hosts

Hosts without encryption keys or with errors

Wrapping It Up

This quick script helps you stay on top of ESXi encryption keys effortlessly. Just copy, adjust if needed, and run. Happy scripting!

Veeam upgrade 12.2 to 12.3 step-by-step in pictures

Pre-upgrade checks

Stop & disable all backup jobs. And then stop all Veeam services.

You can use powershell to stop all Veeam* services: 

Get-Service -Name "Veeam*" | Stop-Service

Mount installation ISO image and run “Setup.exe”

Choose what to upgrade

License Agreement

Upgrade

list of product which will be upgraded

License

If you have already licnesed Veeam, you will see your actual license. Otherwise you can browse local disk for license files or Sign in with Veeam.

Service Account

Database

Database upgrade

Configuration Check

Compatibility Issues

  • New Veeam Threat Hunter service -> https://www.veeam.com/kb1999
  • Selected location does not meet recommended disk space requirements -> extend disk where the Veeam is installed

You can find more details about upgrade in Veeam Help Center -> https://helpcenter.veeam.com/docs/backup/vsphere/upgrade_vbr.html?ver=120

Ready to Upgrade

Upgrade progress

Step 1 of 7:

Step 2 of 7:

Step 3 of 7:

Step 4 of 7:

Step 5 of 7:

Step 6 of 7:

Step 7 of 7:

Finish

Post upgrade

  • check that all services are UP.

Veeam Backup & Replication console which is installed on Veeam VBR server is upgraded automatically.

Components Update

Update

Component update completed

Re-enable previously disabled jobs.

And that’s all 🙂

Centralized ESXi Logs: Quick Guide to Syslog Configuration (WebUI & CLI)

Configuring syslog on your ESXi host is essential for centralized logging and efficient monitoring. Having your logs centrally managed simplifies troubleshooting and helps with compliance and security audits. Below you’ll find an easy-to-follow guide for setting up syslog both via the WebUI and CLI. Don’t forget to verify connectivity and regularly check your centralized logs for effective monitoring.

Configure Syslog Service (vmsyslogd) on ESXi for Remote Logging

1. Configure Syslog Using the vSphere Client

Log in to the vSphere Client and select your ESXi host.

  • Navigate to the Configure tab.
  • Under System, click on Advanced System Settings.
  • Click Edit to modify settings.
  • Filter for Syslog.global.logHost.
  • Enter your syslog server details in the format tcp://hostname:514 or udp://hostname:514 in my case udp://10.20.55.44:514 or with DNS name udp://syslog:514
  • Click OK to apply the changes.

2. Open Firewall Ports for Syslog Traffic

Enable Syslog in Firewall Rules:

  • Still under the Configure tab, go to Networking > Firewall > Ougoing connections.
  • Click EDIT….
  • Filter for syslog
  • Click on Checkboxand Click OK.
  • Now you should see “syslog” in outgoing firewall rules.

3. Verify Connectivity to the Syslog Server

Test Network Connection:

4. Configure Syslog Using ESXCLI Commands (CLI Method)

Set the Remote Syslog Server:

  • Open a console session to your ESXi host.
  • Execute:
esxcli system syslog config set --loghost='udp://syslog:514’

Apply the New Configuration:

esxcli system syslog reload

Check the syslog configuration

esxcli system syslog config get

Open Firewall Ports:

  • Enable the syslog firewall rule with:
esxcli network firewall ruleset set --ruleset-id=syslog --enabled=true

Refresh the firewall settings:

esxcli network firewall refresh

Check the ruleset 

esxcli network firewall ruleset rule list | grep syslog

Tips & Tricks

  • Verify firewall rules to allow syslog traffic.
  • Use consistent naming conventions for easier log analysis.
  • Regularly backup your syslog configuration settings.

By following these simple steps and best practices, you’ll ensure your ESXi host remains efficiently monitored, secure, and compliant.

VMware related KB 318939: https://knowledge.broadcom.com/external/article/318939/

ESXi to Syslog: Troubleshooting Connectivity Issues Like a Pro!

When troubleshooting ESXi network and Syslog server connectivity issues, knowing the right tools can save you hours of frustration. Whether it’s an unresponsive syslog server, blocked TCP/UDP ports, this guide will help you diagnose and fix common connectivity issues quickly.

Key Troubleshooting Tools for ESXi Network Connectivity

Step 1: Verify Basic Network Connectivity

Before checking anything else, confirm that the ESXi host can communicate with the syslog server at a basic network level.

Standard ICMP ping test:

ping <destination-IP>

VMkernel-specific ping (useful for vMotion, NFS, etc.):

 vmkping <destination-IP>

or specify which vmkernel should be used as ongoing interface for ping

 vmkping -I vmk0 <destination-IP>

If these fail, the issue is likely a network routing problem or an upstream firewall blocking traffic.

Step 2: Check TCP/UDP Port Connectivity (netcat)

Even if the server is reachable, the syslog port might be blocked or not listening. Netcat helps determine if a specific TCP or UDP port is reachable.

⚠️ Note: Be aware that netcat doesn’t display an error message when a connection fails—only a successful connection is reported.

Use Cases

Test TCP Port Connectivity:

nc -z <destination-ip> <destination-port>

Test UDP Port Connectivity:

nc -zu <destination-ip> <destination-port>

Step 3: Analyze ESXi Network Connections and Interface Statistics

ESXi provides tools to inspect active network connections and adapter performance.

Check active TCP/UDP connections:

esxcli network ip connection list|grep <port>

If the syslog connection isn’t listed, ESXi isn’t attempting to send logs—double-check your syslog configuration in vSphere.

Check NIC statistics for errors and dropped packets:

esxcli network nic stats get -n <vmnicX>

Persistent errors here could indicate network congestion or misconfigurations.

Final Thoughts: Diagnosing Syslog Connectivity Efficiently

Troubleshooting network issues between an ESXi host and a syslog server doesn’t have to be a headache. Using these tools, you can pinpoint the problem—whether it’s a blocked port, misconfiguration, or network adapter issue—and resolve it efficiently.

Still facing issues? Look at Broadcom KB

How to Quickly Disable a vmnic on ESXi – No Switch Changes or Cable Pulling Needed!

In VMware ESXi, managing physical network interfaces (vmnics) is essential for troubleshooting, maintenance, or reconfiguration. There are times when you need to disable or re-enable a network interface without relying on the network team to shut down a switch port or physically unplugging the cable in the server room. Fortunately, this can be done quickly using the esxcli command-line tool.

Checking Available Network Interfaces

First login via SSH or directly on server console.

Before shutting down a vmnic, it’s good practice to list all available interfaces and check their status:

esxcli network nic list
esxcli network nic list

This command will display a list of vmnics along with their link state, driver, and speed.

Shutting Down a vmnic Interface

To disable a specific vmnic, use the following command:

esxcli network nic down -n vmnicX
esxcli network nic down -n vmnic

Replace vmnicX with the actual interface name (e.g., vmnic5).

Bringing a vmnic Interface Back Up

If you need to enable the interface again, run:

esxcli network nic up -n vmnicX

This will bring the network interface back online.

esxcli network nic up -n vmnic

Use Cases

  • Test network failover scenarios.
  • Identify and isolate network issues by disabling a suspected faulty NIC.
  • Temporarily disable a NIC to measure the impact on network performance and verify load balancing efficiency.
  • Test how virtual machines respond when a specific network path goes down.
  • Shut down a vmnic that is connected to an untrusted VLAN or an incorrectly configured network.
  • Test different network configurations without permanently altering physical connections.

By using esxcli, you can manage network interfaces efficiently.

Let me know if you need any tweaks! 🚀

How to Change vmnic Name on an ESXi Host via Command Line

Renaming or reordering vmnics on an ESXi host can be useful in various scenarios, such as standardizing network configurations or aligning network interface names across multiple hosts. This guide will show you how to achieve this using the ESXi command line.

Listing Current vmnic Aliases

Before making changes, it is essential to check the current vmnic assignments. You can do this with the following command:

localcli --plugin-dir /usr/lib/vmware/esxcli/int/ deviceInternal alias list

This command will return a list of all existing vmnic aliases and their corresponding bus addresses.

Bus type  Bus address          Alias
--------  -------------------  -----
pci       m01000300            vmhba0
pci       m01000b00            vmnic0
pci       p0000:00:07.1        vmhba1
pci       m02001300            vmnic1
logical   pci#m01000300#0      vmhba0
logical   pci#p0000:00:07.1#0  vmhba1
logical   pci#p0000:00:07.1#1  vmhba64
logical   pci#m02001300#0      vmnic1
logical   pci#m01000b00#0      vmnic0

When a nic is controlled by a native driver, then there are actually two aliases associated with the device: a pci alias for the pci device and a logical alias for the uplink logical device.

[root@fs-vsan-05:~] localcli --plugin-dir /usr/lib/vmware/esxcli/int deviceInternal alias list | grep vmnic1

pci       m02001300            vmnic1
logical   pci#m02001300#0      vmnic1

When the logical alias is present, then both the pci alias and logical alias need to be renamed !

Changing a vmnic Name

Make sure you have console access before starting the upcoming steps.

To change the name of a specific vmnic, use the following commands. Replace vmnic5 with the desired new alias and update the bus-address accordingly.

localcli --plugin-dir /usr/lib/vmware/esxcli/int deviceInternal alias store --bus-type pci --alias vmnic5 --bus-address m02001300

localcli --plugin-dir /usr/lib/vmware/esxcli/int deviceInternal alias store --bus-type logical --alias vmnic5 --bus-address pci#m02001300#0

Once the commands have been executed, you need to reboot the ESXi host for the changes to take effect.

reboot

Having Some Fun with vmnic Naming

If you want to experiment and see how ESXi handles long vmnic names, you can try something fun like this:

localcli --plugin-dir /usr/lib/vmware/esxcli/int deviceInternal alias store --bus-type pci --alias vmnic1234567890 --bus-address m02001300

localcli --plugin-dir /usr/lib/vmware/esxcli/int deviceInternal alias store --bus-type logical --alias vmnic1234567890 --bus-address pci#m02001300#0

reboot

While ESXi generally follows a strict naming convention, pushing its limits can be an interesting experiment!

Conclusion

Renaming vmnics in ESXi via the command line is a straightforward process that requires just a few commands and a reboot. Whether you’re restructuring network configurations or just having a bit of fun, these steps will help you modify your ESXi network interfaces with ease.

Related KB: https://knowledge.broadcom.com/external/article/324534/