Re:_Proposal_—_Seamless_Windows_Application_Virtua lization_via_bhyve

->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.