Before you start to make any updates take a snapshot of your Veeam 13 VM and/or take a backup of your database. I am not sure on the majority of what ones are hosting in terms of VBR 13. I upgraded my 12.3 Windows instance to 13.x. I am running SQL Server.

Below is a look at the issue that I saw. I had the Veeam Backup and Replication job that backs up my cluster was showing it had been running since the day before. Right-clicking and stopping the job did nothing. I even killed all the Veeam services on the box and restarted the services and when these came back up, the job was still showing as "running".

Here are the logical steps that I followed to remove the "stuck" job:

1. Confirm that Veeam still thinks the job is running

Basically I had already done this and could see it in the console, but you can also do this from PowerShell with the following:

Get-VBRJob -Name "pveminicluster"

Mine returned:

Job Name       Type            State
--------       ----            -----
pveminicluster Proxmox Backup  Working

Trying the normal stop command did not help either from PowerShell

Stop-VBRJob -Job (Get-VBRJob -Name "pveminicluster") -Confirm:$false

2. Get the Veeam job GUID

To get the GUID of the Veeam job, run this:

(Get-VBRJob -Name "pveminicluster").Id

In my home lab as an example, it returned:

564d17eb-77d8-4fc2-875c-b81658398eef

Save that GUID because it lets you identify all sessions belonging to the job.

3. Determine which database Veeam is actually using

Do not assume Veeam 13 is using PostgreSQL just because PostgreSQL is installed.

My upgraded Veeam server was still using Microsoft SQL Server:

VSERV01\VEEAMSQL2017
Database: VeeamBackup

You can confirm this using the Veeam Configuration Database Connection Settings utility. Then connect to the VeeamBackup database using SQL Server Management Studio.

4. Find all sessions belonging to the job

Run:

USE VeeamBackup;
GO

DECLARE @JobId UNIQUEIDENTIFIER =
'564d17eb-77d8-4fc2-875c-b81658398eef';

SELECT
    id,
    job_id,
    job_name,
    creation_time,
    end_time,
    state,
    result,
    control,
    progress,
    reason,
    usn
FROM 
WHERE job_id = @JobId
ORDER BY creation_time DESC;

This was the query that made the problem obvious. My stuck session looked like this:

id            4C9B5EC7-E1C2-428C-AB71-004CD4D9B86E
job_name      pveminicluster
creation_time 2026-09-04 19:00:00.747
end_time      1900-01-01 00:00:00.000
state         5
result        -1

Meanwhile normal completed sessions had actual end_time values and were no longer in state 5. That session GUID is what we need to remove, not the job GUID.

5. Put the stuck session GUID in a variable

For example:

DECLARE @SessionId UNIQUEIDENTIFIER =
'4C9B5EC7-E1C2-428C-AB71-004CD4D9B86E';

Before deleting anything, verify the exact row:

SELECT *
FROM 
WHERE id = @SessionId;

Also check whether the session appears as its own original session ID:

SELECT *
FROM 
WHERE orig_session_id = @SessionId;

In my case the stuck session appeared in both the id and orig_session_id fields.

6. Check the Veeam session log for that session

Run:

SELECT *
FROM SessionLog
WHERE sessionId = @SessionId;

Our stale session GUID was also present in SessionLog.sessionId, which is why I checked and removed its associated session-log data as part of the cleanup.

7. Stop the Veeam services before changing the database

I would stop Veeam before modifying the session records:

Get-Service *Veeam* | Stop-Service -Force

Verify they are stopped:

Get-Service *Veeam* |
    Where-Object Status -ne 'Stopped'

Do not stop SQL Server itself.

8. Remove the stuck session

At this point I would use a transaction so there is at least an opportunity to inspect what was affected.

USE VeeamBackup;
GO

BEGIN TRANSACTION;

DECLARE @SessionId UNIQUEIDENTIFIER =
'4C9B5EC7-E1C2-428C-AB71-004CD4D9B86E';

DELETE FROM SessionLog
WHERE sessionId = @SessionId;

DELETE FROM 
WHERE id = @SessionId;

Now check:

SELECT *
FROM 
WHERE id = @SessionId;

SELECT *
FROM SessionLog
WHERE sessionId = @SessionId;

If those return no rows and SQL Server did not report any constraint errors:

COMMIT TRANSACTION;

If something looks wrong:

ROLLBACK TRANSACTION;

The important part with this workaround is to delete only the specific stale session GUID. Do not delete everything associated with the job GUID.

9. Start Veeam again

Once you verify everything is good go back in PowerShell:

Get-Service *Veeam* | Start-Service

Give the core services a moment to initialize and then check, replacing with your particular job name:

Get-VBRJob -Name "pveminicluster"

You should see now that you don't have the job running any longer. This worked in my environment

The thing to call out with this VMSA is that VMware ESXi and vCenter are not listed as affected. This one applies specifically to VMware Workstation and Fusion which is at least good news for the enterprise side of things. The two vulnerabilities are:

CVE-2026-59346: VMXNET3 integer-overflow vulnerability

This is the more serious of the two, carrying a CVSS score of 9.3. According to the VMSA, an attacker with local administrative privileges inside a VM using a VMXNET3 virtual network adapter could potentially escape the VM and execute code on the host system. In other words, this potentially crosses one of the security boundaries that virtualization is supposed to give us. The separation between the guest operating system running in a virtual machine and the host operating system.

CVE-2026-59347: HGFS stack buffer-overflow vulnerability

This vulnerability has a CVSS score of 8.1. This one affects VMware's HGFS functionality. A malicious actor with admin privileges inside a VM can potentially use this one to execute code as the VM's VMX process on the host.

Which versions are affected?

Take note of the following versions affected

• VMware Workstation 25H2

• VMware Workstation 26H1

• VMware Fusion 25H2

• VMware Fusion 26H1

The fixed release for both products is:

• VMware Workstation 26H1u1
  VMware Fusion 26H1u1

Workarounds?

None are listed in the VMSA and the remediation is simply to update. 

If you're running VMware Workstation or Fusion, especially on a workstation where you regularly test third-party operating systems, appliances, downloaded VM images, malware samples, or other untrusted workloads, I would put this on the list of things you want to update sooner rather than later. With the VMXNET3 vulnerability, this one is noteworthy since I know I have only used VMXNET3 across the board for years now. So it is hugely common in the VMware world for network connectivity.

This is also another good reminder that the security boundary between the virtual machine and the guest operating system should not automatically be considered perfect. Vulnerabilities in virtual hardware such as network adapters, storage controllers, USB controllers, shared folders, and other emulated devices can definitely happen and possibly provide that path across to the VM boundary.

Recommendation: Update VMware Workstation or Fusion to 26H1u1.

Broadcom advisory:
VMSA-2026-0007: VMware Workstation and Fusion updates address integer-overflow and buffer-overflow vulnerabilities

CVE-2026-59346: CVSS 9.3
CVE-2026-59347: CVSS 8.1
Severity: Critical
Workaround: None
Fixed version: 26H1u1

Read the official advisory here: https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38288

I am just starting out in my home lab, networking, and computer programming journeys, so its a quite a bit all at the same time. Some questions may have generally accepted or 'obvious' answers that never came my way, apologies!

I have recently gotten my home server 'stable', in a rather loose sense. I am running Technetium as DNS and adware/blocking, Traefik for reverse proxy, and beszel for monitoring. A second computer is becoming my new test-bench so I stop taking the entire house offline every reboot.

I'm at the point where my main DNS server, a Raspberry Pi, needs some updates and a reboot, which made me start asking the question - is there a good way to back up DNS servicing on my local network to deal with hardware failure or shutdown, either intentional or accidental? My router only has one box to enter a DNS IP, otherwise I could just duplicate the technitium container on two devices. Is everyone just very deliberate about when they schedule shutdowns and reboots of their home devices?

Here are a few of the details. Docker says the new VMM should be faster container startup and better file I/O, along with better memory management. The memory side seems to be the more interesting part top me since Docker VMM can give back unused memory to the host when any of the containers are idle. I have seen Docker Desktop eat through RAM many times, so if this improves, I will take it.

File sharing is another area that seems interesting to test. Bind mounts and host-to-container file access have been a whole lot slower than just natively running Docker containers on Linux. Docker VMM is available starting with Docker Desktop 4.86.

On Windows you can enable it under:

• Settings > General > Docker VMM

Mac users who are using Docker VMM will automatically get the rebuilt engine after they upgrade. Docker is looking to be targeting somewhere around the end of October 2026 for GA from what it looks like and the interesting part is that they plan to make Docker VMM the default engine on Mac, Windows, and even Linux. Docker is also using the virtualization engine  for Docker Sandboxes, so it looks like this is becoming a bigger part of Docker's architecture moving forward.

I'm definitely going to play around with this one. I'd like to compare memory usage and container performance against what I see with the current Docker Desktop setup and see if the difference is actually noticeable.

Anyone tried the beta yet? Seeing any differences?

Source:

https://www.docker.com/blog/docker-vmm-public-beta/

Step 1: Force APT to use IPv4

If you are not using IPv6 in your environment, this keeps APT from wasting time trying broken or unreachable IPv6 paths.

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

You can make sure it "sticks" with the following:

cat /etc/apt/apt.conf.d/99force-ipv4

You should see something like this:

Acquire::ForceIPv4 "true";

Step 2: Change Ubuntu repositories from HTTP to HTTPS

This is the one that I found made the biggest difference, since it looks like it is hitting cloudflare IPs. On Ubuntu 24.04 (Noble), edit the .sources file with this:

sudo sed -i \
's|http://archive.ubuntu.com/ubuntu|https://archive.ubuntu.com/ubuntu|g;
 s|http://security.ubuntu.com/ubuntu|https://security.ubuntu.com/ubuntu|g' \
/etc/apt/sources.list.d/ubuntu.sources

Make sure of your changes.

cat /etc/apt/sources.list.d/ubuntu.sources

You should now see:

URIs: https://archive.ubuntu.com/ubuntu

and this also:

URIs: https://security.ubuntu.com/ubuntu

Step 3: Refresh APT

sudo apt clean
sudo apt update

Step 4: Test download speed

To make sure of your speed improvement, below is just an example that I used since I was trying to install JAVA:

wget -4 -O /dev/null \
https://archive.ubuntu.com/ubuntu/pool/main/o/openjdk-17/openjdk-17-jre-headless_17.0.19+10-1~24.04.2_amd64.deb

45.86 MB in 3.2 seconds
≈14.5 MB/sec

Veeam Backup & Replication v13.1 new features

• VM replication for Proxmox VE
  • Native VM replication jobs are now there for Proxmox VE.
  • Supports host-to-host replication, cross-datacenter replication, and replication across different storage types (awesome)
• Instant VM Recovery to Proxmox VE
  • Instantly recover VMs from backups created on other supported platforms directly into Proxmox VE
  • Lets workloads run immediately before migrating them to production storage
  • ***Note*** - This is listed as Experimental Support in v13.1
• VLAN tagging during restore
  • Restore and worker VMs can now be assigned VLAN tags
  • Useful if you are still using VLAN-based networking instead of Proxmox SDN
• Automatic VirtIO driver injection
  • Restoring VMs from VMware, Hyper-V, or other supported platforms into Proxmox automatically injects VirtIO drivers.
  • Better cross-platform migration
• Complete Proxmox Web UI support
  • Backup jobs
  • Restore operations
  • Infrastructure management
  • All available through the Veeam Web UI the same as VMware and Hyper-V.
• Advanced RBAC for Proxmox
  • Granular role-based permissions can be assigned to specific VMs. But also for jobs, categories, and infrastructure objects.
  • ***Note*** - This is listed as Experimental Support in v13.1
• Improved restore job statistics
  • Better restore progress reporting and visibility in the Web UI.

Other Proxmox-related improvements found in v13.1

• Universal Hypervisor API (UHAPI)
  • New framework allowing additional hypervisors to integrate with Veeam more quickly
  • Shows Veeam's continued support and development in multi-hypervisor support, which benefits Proxmox adoption
• Expanded "restore from anywhere" support
  • Many newly supported hypervisors (Citrix XenServer, XCP-ng, Sangfor aSV, Platform9, VergeOS) can restore workloads into Proxmox VE using Instant Recovery (currently Experimental)
• Web UI Instant Recovery from any platform
  • Image-level backups from supported platforms can now be restored through the Web UI, further simplifying migrations into Proxmox environments
• Cloud Connect enhancements
  • Service providers can now perform entire VM restores directly to Proxmox VE for tenant backups
• REST API additions
  • New REST API endpoints for Proxmox VE backups, restore points, sessions, infrastructure queries, and job control

Download the full "What's new" PDF from Veeam here: veeam_backup_13_1_whats_new_wn.pdf.

My takeaway

If you have been wondering if Veeam was "all in" on Proxmox, this release to me definitely seals that discussion. Veeam looks to be committed to Proxmox as a major platform and I think this will further facilitate customers getting off Broadcom and onto a platform that is reasonably priced again.

What are your thoughts? Is your organization migrating fully to Proxmox? Looking at Veeam or already a Veeam customer? I would be curious to know what you think.

docker system prune -a -f

But I still had a lot of disk space used. Pulling out the trusty WinDirStat tool that I have loaded, I started looking at the Largest Files on my machine and found that my docker_data.vhdx file was around 261 GB! 

Even after clearing up old images, the VHDX was still large. So we can use diskpart to compact the VHDX like this. First shutdown WSL and see if you have anything else running:

wsl --shutdown
wsl --list --running

Now, we use diskpart to shrink the VHDX. Launch diskpart:

diskpart

Then run the following commands, replacing the vdisk file path with the file path for your machine:

select vdisk file="C:\Users\localadmin\AppData\Local\Docker\wsl\disk\docker_data.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit

Hopefully these simple steps helps someone else facing this same issue!

Brandon

Here is the GitHub: https://github.com/ffind-dev/pve-ups

If you've ever configured NUT, you know it is super powerful, but it is also known to not be for the faint of heart. It can be more complicated than what many home lab users actually need. This project takes a different approach by focusing on a graceful Proxmox shutdown during a power outage. The author was transparent that he vibe coded the tool. But honestly, it looks really amazing.

From what I've read, it runs as a lightweight Debian LXC and provides a web-based wizard to set things up instead of making you edit NUT configuration files. It communicates with Proxmox using the API. I like this as it means you don't have to install agents on each node or rely on SSH for shutdown operations.

A few features that stood out:

• Web UI for configuration
• Uses Proxmox API tokens with few permissions actually needed
• Gracefully shuts down VMs and LXCs before powering off the hosts
• Keeps the host running the appliance online until the rest of the cluster has shut down
• Very lightweight resources are needed.

One important limitation is that it currently supports UPS units with an SNMP management card only. If you're using a USB-connected UPS, NUT is still the recommended solution for that configuration..

I haven't had a chance to test this in my own lab yet, but I really like seeing projects that simplify common Proxmox management tasks. For those of us already running network-managed APC, CyberPower, or Eaton UPS units, this looks like it could be a nice alternative.

Has anyone here already tried this or looking at deploying it? If so, I'd be interested to hear:

• Which UPS are you using?
• How was the setup process?
• How has it behaved during actual power events?

Looking forward to hearing everyone's experiences.

machine:
  kubelet:
    extraConfig:
      # Start GC sooner than the default ~85%
      imageGCHighThresholdPercent: 75
      # Keep reclaiming until under this
      imageGCLowThresholdPercent: 65
      # Don't delete brand-new unused images
      imageMinimumGCAge: "2m"
      # Also drop unused images older than 7 days even if disk isn't critical
      # (this is what should eat old gitlab-ee / pulse tags)
      imageMaximumGCAge: "168h"

Apply the config patch on all nodes that have disk pressure and Talos will begin discarding old images immediately. Comparing from before I ran the patch to after:

One of the challenges I think that most of us have is simply keeping track of everything. It's easy to spin up a new VM, add another mini PC, connect an IoT device, or build out another VLAN. Before long you're wondering where that random IP address came from or what server is actually running a particular service. I have been there MANY times.

LAN Orangutan looks like it aims to solve that problem. Instead of just running a one-time network scan, it provides a lightweight inventory of your network with a clean web interface where discovered devices are stored and organized over time. It uses Nmap for discovery. So it definitely comes from good "stock" with its architecture for scanning.

Some of the features that caught my eye with this project includes:

• Automatic network discovery
• Multi-network scanning
• Device inventory with persistent records
• Device labels and notes
• Tailscale support
• Modern web dashboard
• CLI with JSON output
• Cross-platform support for Linux, Windows, and macOS
• Single binary deployment

The Tailscale support is especially interesting. I know quite a few of us have multiple home labs or remote sites connected with Tailscale. So this is super interesting being able to inventory devices across those networks.

I also like that the project doesn't appear to be trying to become an all-in-one monitoring platform. There are already plenty of tools in this space that can collect metrics, monitor uptime, or manage enterprise devices. LAN Orangutan is instead laser focused on that simple question of finding out "what devices are on my network?"

According to the roadmap, the developers are also planning features like scheduled scans, notifications, historical tracking, and an API, which could make it even more useful for automation and keeping home lab documentation up to date.

I'm curious how it compares with some of the other tools many of us already use, such as:

• NetBox
• NetAlertX
• LibreNMS
• Uptime Kuma
• Smokeping
• ArpWatch

LAN Orangutan looks like it could fill a nice niche as a lightweight discovery and inventory tool without bringing along a lot of additional complexity.

I'm planning to spin this up in my own lab and see how it performs across multiple VLANs and remote networks. If it works as well as it looks, I could see it becoming another useful utility to keep around alongside the rest of the home lab toolbox.

Check out the project on Github here: 291-Group/LAN-Orangutan: LAN Orangutan is a lightweight network scanner with persistent device labeling, multi-network support, and Tailscale integration. Built by 291 Group.

Has anyone here already tried it? I'd be interested to hear how well it performs and if

you've found any features that really stand out.