How do I "force" VMs to appear in same "actual" desktop as the launching VirtualBox Manager?

[pax]

I use VirtualBox 7.0.14 on a Windows 10 Pro host.

On the host I use Sysinternals' Desktops (https://learn.microsoft.com/en-us/sysin ... s/desktops) to create 2 desktops, named "Default" and "Sysinternals Desktop 1". These are "actual" desktops created via the CreateDesktop() win32 api, not virtual deaktops that are a feature of Windows 10.

In general when an app is launched on an actual-desktop, any apps _it_ then launches appear on that same desktop, but not all apps are that well behaved: for example, if I launch Notepad.exe on a desktop other than Default, then click Help > Send Feedback, the resulting Feedback Hub is opened in desktop Default.

Unfortunately both the "VirtualBox Manager" GUI and VBoxManage.exe exhibit similar behavior: if there are no VMs already running then newly launched VMs appear in the desktop of the launching VirtualBox Manager; if there are VMs already running, newly launched VMs appear in that desktop (and cannot be moved to another desktop due characteristics of Windows' actual-desktops; pls see link above)

I've tried running `VBoxManage.exe startvm ...` via a CreateProcess() win32 api call with an explicitly set the target desktop in its `StartupInfo` struct, and results are the same -- the launched VM still appears in the desktop of any already-running VMs.

Virtualbox 6.1 exhibits the same behavior.

So my question: is there a way to "force" VMs to appear in same "actual" desktop -- perhaps via some "setextradata" magic -- as the launching VirtualBox Manager?

===== steps to reproduce

-- windows host w/ virtualbox 7 and at least 2 guests
-- create a desktop shortcut to VirtualBox Manager, if you don't already have one
-- start guest 1; leave this running
-- download Sysinternals Desktops from https://learn.microsoft.com/en-us/sysin ... s/desktops ; this is a portable app that doesn't need to be "installed", but once started you'll need to log off to shut it down
-- run Sysinternals Desktops; click its systray icon, then click desktop 2 to create and switch to it
-- click the desktop icon to start VirtualBox Manager (in desktop 2); start guest 2; if your experience is the same as mine, the guest 2 VM appears in desktop 1

[scottgus1]

This one I'm definitely fuzzy on. I downloaded Desktops but did not run it. I did not see any instructions in a ReadMe that may include a command line variant of the Desktops app.

Virtualbox actually spawns sub-processes (some 3 or 4) to run a VM on a Windows host. If this spawning process does not account for Desktops, admittedly 3rd-party enough that the Virtualbox devs probably don't program for it, then you may be stuck taking whatever desktop the final VM-running process ends up on. And according to the Desktops website:

Windows doesn't provide a way to move a window from one desktop object to another,

So you may have a work routine centered around Desktops that isn't compatible with Virtualbox.

Windows 10 comes with its own built-in multi-desktop feature, doesn't it? When I three-finger swipe up on my laptop trackpad there is an overview window that offers a new desktop. Does that perform any different than the Sysinternals app?

[pax]

Sysinternals' Desktops doesn't have any commandline switches, as far as I know. FYI the desktops it creates are via Windows' own CreateDesktop() api, which is how Windows' own "Default" desktop is created. You/we could create our own desktop with CreateDesktop(); sysinternals simply packages that into an app. All to say it's not quite "third party" in the sense of something very different from Windows' own operation.

The virtual desktops introduced in Windows 10 are, well, "virtual", are all created inside the "Default" actual-desktop and ~ show/hide apps when switching among these virtual desktops; the CreateDesktop() api is not involved; at the end of the day there is only 1 "actual" desktop.

Virtual desktops don't work well for my use case because one of my VMs starts apps on the host, and I'd like that VM and host-apps it launches to be confined to their own desktop (in virtual desktops launched apps appear on the current/active virtual desktop, and steal focus from or otherwise interrupt ongoing interactive work). I also have other VMs doing other work, and I would like _those_ on a different desktop. A standard approach for desktop-affinity with virtual desktops is to use a virtual desktop manager that "watches" for launched apps and moves them into specific virtual desktops -- VirtualSpace does this best among several managers I've tried -- but there's still a "flash" when an app is spawned/moved, often w/ loss of focus as well.

It does sound like VirtualBox-on-Windows doesn't take "actual"-desktops into account. Where would I submit this as a bug or enhancement request?

[scottgus1]

You can submit an enhancement request on the Bugtracker. This does not look like a bug to me, more like something that you'd want Virtualbox to be compatible with that it isn't compatible with now.

FWIW the devs are busy putting out other more long-standing fires. You may do better trying to program this yourself by editing the source code and building in your edits. User-contributed code is considered for inclusion.

[pax]

True, along the spectrum of bug..omission it tends toward the latter.
I was hoping setextradata options to VBoxManage.exe would help; guess not, but hope springs eternal.
Thx for the link.

[pax]

The following are some crude stabs at understanding what to address:

I see from Windows Task Manager that starting VirtualBox Manager launches 3 processes: VirtualBox Manager as a foreground process; "VirtualBox Global Interface" and "VirtualBox Interface" as background processes. Thereon, each launched VM adds 3 processes that show up, all named "VirtualBox Virtual Machine", 1 forground, 2 background.

The "VirtualBox Interface" background process seems to be used contnuously when VMs are running; kill it, and VMs crash. The "VirtualBox Global Interface" shows a sub-process named "Virtualbox system service"; that service is described in Windows' Services applet as "Used as a COM server for VirtualBox API." From https://learn.microsoft.com/en-us/answe ... lt-desktop / RLWA2's response Dec 30, 2021, 5:06 AM, I hoped setting AppIDFlags per https://learn.microsoft.com/en-us/windo ... appidflags would help; set it for just about every VirtualBox-related classid ... and no difference in behavior.

What I've found is that VMs appear on the desktop in which VirtualBox Global Interface is running. You can stop that service, restart it from another desktop, and subsequently launched VMs appear there. At least one downside to stop/starting the service is that already-running and newly-launched VirtualBox Manager/s don't correctly display the running statuses of VMs on other desktops. Probably other gotchas as well.

[scottgus1]

Interesting insights. Another thought to consider: the three VirtualboxVM.exe processes that get spawned when running a VM are part of the Windows host hardening process, so baddies on the host can't use Virtualbox to get greater privileges to to bad stuff. Keeping that hardening stack intact will be essential.