VMs are listet multiple times in different tabs

Apps and Virtualization
1

After Updating my machine from 24.10.2.3 to 25.04.2 I am a bit confused regarding containers and VM.
In 24.10.2.3 I had 3 VMs installed, Windws, Debian an CentOS. Als three where showing in the VMs tab. Now after appling the patch from here I can see 2 of them (Windows and Debian) in the Containers tab

Bildschirmfoto 2025-08-03 um 12.59.53
Bildschirmfoto 2025-08-03 um 12.59.533360×972 210 KB

and all three in the VMs tab, ignore the RockyLinux.
Bildschirmfoto 2025-08-03 um 13.00.27
Bildschirmfoto 2025-08-03 um 13.00.273360×872 141 KB

If I want to start the Windows VM via the VM tab it is not working and shows me the following error:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/middlewared/api/base/server/ws_handler/rpc.py", line 323, in process_method_call
    result = await method.call(app, params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/api/base/server/method.py", line 52, in call
    result = await self.middleware.call_with_audit(self.name, self.serviceobj, methodobj, params, app)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 911, in call_with_audit
    result = await self._call(method, serviceobj, methodobj, params, app=app,
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 720, in _call
    return await methodobj(*prepared_call.args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/api/base/decorator.py", line 93, in wrapped
    result = await func(*args)
             ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/plugins/vm/vm_lifecycle.py", line 57, in start
    await self.middleware.run_in_thread(self._start, vm['name'])
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 627, in run_in_thread
    return await self.run_in_executor(io_thread_pool_executor, method, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/main.py", line 624, in run_in_executor
    return await loop.run_in_executor(pool, functools.partial(method, *args, **kwargs))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/middlewared/plugins/vm/vm_supervisor.py", line 68, in _start
    self.vms[vm_name].start(vm_data=self._vm_from_name(vm_name))
  File "/usr/lib/python3/dist-packages/middlewared/plugins/vm/supervisor/supervisor.py", line 162, in start
    raise CallError(
middlewared.service_exception.CallError: [EFAULT] VM will not start as DISPLAY Device: 0.0.0.0:5901 device(s) are not available.

The only way I can start this VM is via the Containers tab.
If I Shutdown the Debian VM in the VM tab as well as in the Containers tab and then try to start via the VM tab it is also not working.

At the moment it is more confusing to me then ever bevor.

How can I manage it the all the VMs are controllable via die VMs tab and not showing in the Containers tag as well?

2

If you had 25.04.2 working why did you apply the “patch”? That patch was only a temp solution to the VM’s dont show up after update because they had a display VNC with no password.

3

Delete the classic “ghost” VMs, if you have “Container” VMs.

Or, extract the zvols from container VMs, and reassociate with the classic VMs.

Your choice.

4

The VMs showed up after applying the patch. Before I had the error with “Cannot Retrieve Response”.

5

They were always there. The patch fixed the tab’s ability to retrieve the response.

6

How can I do this?

7

There are a few ways, but here’s what I did.

You could also just rename your Zvol back into place, but I went through the extra steps shown in the link above because I felt it was safer. If the process had not gone successfully, I knew the VM could still be run under the container tab. I didn’t want to take the chance of screwing something up and losing Zvol all together .