Re:_Proposal_—_Seamless_Windows_Application_Virtua lization_via_bhyve

Hmm. Actually it's... It's true. I was overly cautious there  looking at
Looking Glass's actual requirements, iGPU + dedicated GPU is officially one
of their two supported configurations (the other being iGPU + vGPU), and
it's explicitly called out as the common laptop/desktop scenario. Your
Aorus Pro setup (iGPU + GTX 1060 + RTX 2080 Ti) is well beyond what's
needed.
The only real caveat in their docs is that if the iGPU is used on the host
side, you may hit some bandwidth/resolution limits since it shares system
RAM  but that's a minor tradeoff, not a blocker. So GPU passthrough is much
more broadly achievable than I gave it credit for. Stepping back a bit  I'd
love to hear what you think of where this thread has landed overall.
Between the qemu-bhyve install/run workflow, bringing your own Windows ISO
to sidestep licensing, sshfs-win or a jail for file access, and now Looking
Glass for near-native seamless display, it feels like the pieces could
actually fit together into something coherent.
Do you think this is realistic to build, or are we underestimating the
effort? My hope is that if something like this existed, it could genuinely
make FreeBSD a more viable desktop choice for people who are currently
stuck on Windows just for a handful of apps


8 Ağu 2026 Cmt 14:03 tarihinde Mario Marietto <marietto2008@gmail.com> şunu
yazdı:

> ->The main constraint I see is GPU passthrough requirements Looking Glass
> typically needs >dedicated/secondary GPU (or at least IOMMU-capable
> hardware) for good performance, which not >every FreeBSD desktop user will
> have
>
> Are you sure ? Today every mobo has one integrated gpu embedded inside it.
> And a dedicated GPU for intensive tasks. I regularly run the Intel GPU
> integrated inside my Aorus Pro with one Intel I9 cpu on top of it and two
> dedicated GPUs I use for programming. A GTX 1060 and one RTX 2080 ti. I
> think this is the common scenario for most people.
>
> On Sat, Aug 8, 2026 at 2:53 PM Asiye Sarıyıldız <asiyee994@gmail.com>
> wrote:
>
>> Looking Glass is a brilliant addition to this idea exactly the kind of
>> "seamless" experience I was hoping for, and much better than VNC in terms
>> of latency. Having the client run natively on FreeBSD while the server runs
>> inside the jail/VM with Windows would make the whole thing feel like a real
>> native app rather than a remote session.
>> The main constraint I see is GPU passthrough requirements Looking Glass
>> typically needs a dedicated/secondary GPU (or at least IOMMU-capable
>> hardware) for good performance, which not every FreeBSD desktop user will
>> have. Maybe we could fall back to a VNC-based mode when passthrough isn't
>> available, and use Looking Glass as the "fast path" when it is.
>> Combined with the qemu-bhyve install/run workflow and sshfs-win (or a
>> jail-based file mount) for file access, this is shaping up to be a pretty
>> complete picture. Really appreciate you connecting the dots here.
>>
>> 8 Ağu 2026 Cmt 13:48 tarihinde Mario Marietto <marietto2008@gmail.com>
>> şunu yazdı:
>>
>>> >Thanks for the feedback Actually what I had in mind is closer to how
>>> WSL2 works on Windows
>>>
>>> qemu-bhyve install Windows (and here you should insert the WIndows DVD
>>> to avoid licensing issues).
>>> Windows will be installed inside the sandbox. Actually I like the idea
>>> to use sshfs-win
>>>
>>> Later,you can do : qemu-bhyve "tool". And again the tool will be
>>> installed inside the sandbox.
>>>
>>> This is the perfect chance to port Looking Glass,with the client part
>>> which runs on FreeBSD and the server part inside the jail where Windows is
>>> installed :)
>>>
>>> So nice.
>>>
>>> On Sat, Aug 8, 2026 at 2:39 PM Asiye Sarıyıldız <asiyee994@gmail.com>
>>> wrote:
>>>
>>>> I haven't yet considered how to resolve the licensing issue; if we were
>>>> to implement something like WSL2, it shouldn't come pre-installed the user
>>>> would need to download the ISO or a similar file themselves.
>>>>
>>>> 8 Ağu 2026 Cmt 13:35 tarihinde Asiye Sarıyıldız <asiyee994@gmail.com>
>>>> şunu yazdı:
>>>>
>>>>> Thanks for the feedback Actually what I had in mind is closer to how
>>>>> WSL2 works on Windows: it runs a real Linux kernel inside a lightweight
>>>>> Hyper-V VM, but the user never manages the VM directly  file sharing,
>>>>> networking, and even GUI apps (via WSLg) are fully integrated, so it feels
>>>>> native.
>>>>> I'd love something like that for FreeBSD + Windows apps: bhyve running
>>>>> a minimal Windows VM in the background, but the user just does qemu-bhyve
>>>>> install adobe and interacts with the app almost like a native FreeBSD
>>>>> program — no manual VM management, no VNC. Your container/jail idea for
>>>>> file access sounds like a great way to get part of that seamlessness
>>>>> without needing full window integration.
>>>>> Regular Wine can't run Adobe or Teams reliably because of missing
>>>>> Win32 API coverage, which is exactly why I think a real Windows kernel
>>>>> (even a minimal one) is needed rather than translation
>>>>>
>>>>> 8 Ağu 2026 Cmt 13:18 tarihinde Mario Marietto <marietto2008@gmail.com>
>>>>> şunu yazdı:
>>>>>
>>>>>> >Yes, I know about Wine, but Wine tries to replicate Windows APIs
>>>>>> which often causes compatibility >bugs or performance overhead. My idea
>>>>>> with bhyve was closer to a lightweight virtualized Windows >kernel
>>>>>> operating in the background, where the GUI windows are seamlessly
>>>>>> integrated into the >FreeBSD desktop environment (like seamless mode in
>>>>>> VirtualBox or WSLg in Linux). I thought bhyve >could achieve better raw
>>>>>> hardware compatibility for specific professional Windows apps. Example
>>>>>> >Adobe
>>>>>>
>>>>>> Your idea is intriguing me,but probably not in the same way you are
>>>>>> thinking about it. In my vision I would keep the way wine works almost
>>>>>> intact,but I would use plane bhyve or qemu accelerated with bhyve instead
>>>>>> of wine,so that we can have something like this :
>>>>>>
>>>>>> qemu-bhyve install or run "application".
>>>>>>
>>>>>> The tool (for example Adobe) will be installed inside a sandbox after
>>>>>> having issued "install" or it can be run in the same way. And you can have
>>>>>> direct access to the files installed without accessing inside the vm with
>>>>>> vnc viewer,but easier,we can install a container (podman ? a jail ? ). It
>>>>>> sounds nice to me.
>>>>>>
>>>>>> ERRATA CORRIGE : we can install the desired tool directly inside a
>>>>>> container (podman ? a jail ? sshfs-win ?
>>>>>>
>>>>>>
>>>>>> https://forums.freebsd.org/threads/windows-drive-mapping-to-freebsd-directory-fails-with-sshfs-win.96474/
>>>>>>
>>>>>> What do you think ?
>>>>>>
>>>>>> On Sat, Aug 8, 2026 at 12:32 PM Asiye Sarıyıldız <asiyee994@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Yes, I know about Wine, but Wine tries to replicate Windows APIs
>>>>>>> which often causes compatibility bugs or performance overhead. My idea with
>>>>>>> bhyve was closer to a lightweight virtualized Windows kernel operating in
>>>>>>> the background, where the GUI windows are seamlessly integrated into the
>>>>>>> FreeBSD desktop environment (like seamless mode in VirtualBox or WSLg in
>>>>>>> Linux). I thought bhyve could achieve better raw hardware compatibility for
>>>>>>> specific professional Windows apps. Example Adobe
>>>>>>>
>>>>>>> 8 Ağu 2026 Cmt 11:30 tarihinde Mario Marietto <
>>>>>>> marietto2008@gmail.com> şunu yazdı:
>>>>>>>
>>>>>>>> ---> have you tried wine11?
>>>>>>>>
>>>>>>>> I think he wants to "duplicate" the look and feel and the exterior
>>>>>>>> working of wine,but using bhyve at the place of wine ? Did I understand
>>>>>>>> correctly ?
>>>>>>>>
>>>>>>>> On Sat, Aug 8, 2026 at 12:17 PM Tomek CEDRO <tomek@cedro.info>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> have you tried wine11?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>>>>>>>>
>>>>>>>>> On Sat, Aug 8, 2026, 00:22 Asiye Sarıyıldız <asiyee994@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I've been thinking about a potential enhancement to bhyve that
>>>>>>>>>> could make Windows application compatibility much smoother for FreeBSD
>>>>>>>>>> desktop users.
>>>>>>>>>> Currently, running Windows applications (e.g., Adobe products)
>>>>>>>>>> requires manually setting up a full Windows VM in bhyve — creating disk
>>>>>>>>>> images, configuring UEFI/BIOS, installing drivers, and manually managing
>>>>>>>>>> the guest OS. This works, but it's a heavy, manual process compared to
>>>>>>>>>> solutions like Wine/Proton on Linux or Parallels' seamless mode on macOS.
>>>>>>>>>> What if bhyve offered a more automated, "appliance-style"
>>>>>>>>>> workflow: the user supplies their own Windows installation ISO (and their
>>>>>>>>>> own license), and bhyve handles VM provisioning, NT kernel boot
>>>>>>>>>> configuration, and required virtio/driver setup automatically — with
>>>>>>>>>> minimal manual steps. Since the user brings their own ISO and license, this
>>>>>>>>>> avoids any licensing or redistribution concerns on the project's side.
>>>>>>>>>> Ideally, this could eventually extend toward seamless window integration
>>>>>>>>>> (running individual Windows apps like Adobe software without exposing the
>>>>>>>>>> full Windows desktop), similar to what VMware Fusion or Parallels offer on
>>>>>>>>>> macOS.
>>>>>>>>>> I understand this raises real challenges — driver signing, GPU
>>>>>>>>>> passthrough for apps like Adobe's Creative Suite, and the significant
>>>>>>>>>> engineering effort seamless integration would require compared to a
>>>>>>>>>> standard full-VM setup.
>>>>>>>>>> Is this something the core team has considered, or is it already
>>>>>>>>>> covered by existing tools (e.g., vm-bhyve, or work in progress)? I'd
>>>>>>>>>> appreciate your perspective on whether this is a realistic direction for
>>>>>>>>>> bhyve, or whether the complexity outweighs the benefit compared to just
>>>>>>>>>> using a standard full VM setup.
>>>>>>>>>> Thank you for your time and for your work on FreeBSD.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mario.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mario.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mario.
>>>>>>
>>>>>
>>>
>>> --
>>> Mario.
>>>
>>
>
> --
> Mario.
>