Brandon

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

Usually what I would recommend with Technitium is that you would create two Technitium servers and now there is native clustering as of Technitium v15. You can connect two Technitium servers together for clustering those and having high availability to your DNS infrastructure. This allows you to have a primary and secondary DNS server for clients/servers. 

I think one of the best ways you could have a "single" IP but also have two servers servicing your infrastructure is that you could have two servers fronted by Keepalived. You could load Keepalived on both of your container hosts. Then you would use something like the following configuration, that they call a "tracking script" I believe:

vrrp_script chk_technitium {
    script "/usr/local/bin/check-technitium.sh"
    interval 1
    timeout 1
    fall 2
    rise 2
}

The above config will check DNS every 1 second and after 2 failures, it will consider the check failed. This way you could populate with the virtual IP of the Keepalived config and then it will forward DNS requests to the master server (configurable), until the container goes down. Then, the tracking script will fire and recognize the DNS service is down and will failover the solution to the secondary server.

Let me know if this helps.

Brandon

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?

Chris

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/