From nobody Sat Aug 08 13:27:51 2026 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4hHMKY3s4cz6ngZk for ; Sat, 08 Aug 2026 13:28:33 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4hHMKX5qXkz3YRC for ; Sat, 08 Aug 2026 13:28:32 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-2cf50c6f235so4780345ad.0 for ; Sat, 08 Aug 2026 06:28:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1786195709; cv=none; d=google.com; s=arc-20260327; b=M77noluoNu2soZQf7R19pa0Ey8+hGjaLjJovJ3YM7JwuX+1cDEjbK9rzmxcIHNS/rv YsqRsf15rPa/JxSRdnfr4zchFyYU+ytLbbBE7IfDDykH9iMVeqYG4nzcyG3pwH05ryZq DOC9CGmf/bIli/8AZvDrai6o2pSf/oNC8LaeRi9X5r/dm3GsgC5WnFrfWT3rTq1pMeCB mPq0nhUkaZLBokyOYVEqgBBeazxY8AUF9Eox7d9JKmeIUXtddzmY+rm4xjyhLMuNf3mW BPY8JSBf7BA8eJjwrRB6ltIZ5fJK2K6wZQmsl9ksoCeSn1zFq1g1seNffM4GEROHyDVg 67KA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Qy73F31RWtrCzEw3dYDKCc2MUy1lXWucRbMUyXYjIHM=; fh=Xcoq4M4ryPnTp9IXmbxELnMEgWZVm3SgTbUPNrR76ew=; b=ndB388oCf6yym28hyf5LR+Gnao551UeiVF2nVAFf9TvsgSjpRanY0+JQJfvwxdGk9S dvsIDsYllTcOyYwYWuScVq47xIH3pNblrtD7mdeB28b0vsyJamOfXhndNUzBLMCkCFQc GGSNKaIAOr+kxB6kmx8vlp0EPQGr99l+fgkO1QyP44GACSfqQvLY8lo7ZHNQ6OvLwMdw vXtMsedbNCs/UKv4690WoixW1kqpjf8ojotulKerbjE7Lch6FvHu9ZsUL4s5Z3MKiBIt uZK/L4nYT4KMJO1dSZEr7NES9DhdwkRRUENKkpnNOTUJEaojMr4KY0U9t2xBlSrgiU8O R8KQ==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786195709; x=1786800509; darn=freebsd.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Qy73F31RWtrCzEw3dYDKCc2MUy1lXWucRbMUyXYjIHM=; b=g52CUwYQLL7otOBQ4/bzKSIuujtXf6cL0UK6JEeFCggQENJFBYYJRRW53K5xu5ZT1b 9mnIZlKRUWKvURdgCxpc1YMjoGLCeHkZ+q434wqwDB45mr/KMPuXXIQwQGcvq4zvhW2X 36p3Fg0ny5dbol1L2GyHLWNaxc+6EW/wyV+9rRzjh39/lKNxQhR8x9/+FbZOqx+2EYSw h1pWOH+itM7tWfh1TIgYqaSTlKx0vHCVM4rylsZ2dYp5rK3LEEc21wsdZyfETYVZFjjt /rGoqRGngaFwl6vG4/mn0c/tPQRgi9bHDacrTeaItcJVBzglUmr82ML7NyQMl9eZZcJx rk7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786195709; x=1786800509; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Qy73F31RWtrCzEw3dYDKCc2MUy1lXWucRbMUyXYjIHM=; b=nrZQmLu1+cQ2eRe1J98eA65kRoYp+wNHrsoFGKMwnTom+jrcfezb1mssHUqdSZMYtA Zrm9i7X7tzsn6a/MSyQCxeqCUkJrD4ARELIhK4TF3lSjWIfpd6FzA3nL+tGMgJpqjsVE RR396Wb4jlbbyDzzsNe6iN4BjndmyFEjfuDIfb0XhnpXxwS8Jflp32bVUYDgqYSftQcY 3H+RMlwGaPgUrhzuLqv8Ey2Drokc+nYjF1Zag3jS1WKV0hyfNsv49GYGYVYn4ZEkZ/H+ GLZweBtk8njC2x9ImpeYelwJE9TGlfMnZbS00tv2zvrrYNe2NWEjPqjC8qoTGBjMJyB2 h0fA== X-Gm-Message-State: AOJu0Yy7nomHNNhWspZxGzwHebJvZDzfbzMKK+tu+klseZAvcUravtt9 ZaH3blAqP08Z+Fc/E4vSVyXp1Py0Lzy0kk4rzO68Aqj/o/fmlRa9m/kw2w+na68RLwX/bb5uY1v f/fEF5Rdkb023BUGpNE2kaUpcXIiNTPsZj3Tw X-Gm-Gg: AR+sD10lydhn3jbg1hD2/6WusxgwhCfTFh/xzx/hFSqxD5fnHBxO/M8HgadyRVcBR8i 5JbUSBcQWByBfYQhuX+J9N7BlS7+ItypbTeDMPHfMJ2xZQLprNZf+GZY/ufGdZ6wi/v/W7r043G uL2+cpPmOLYzIGdv/n1g0hjig8YnzJCXPpRuIIIxOGejC88BLglmCGBujBC1M+Tw1qIyKevCgdH vy/V0ZC91PxiRp6sDT0A2dltS4EgLwch8bGYzQyt3dcMkdYou7uElxUKJw071RLrXwJ8bKmWk4+ ay1w0JaiB6w5SyY5Vgbhleh+6BLHF5ZvsGc6L/ov4fOs3vXw+fuJTVHFGOKavW7yOV4HRhJRLSf dmt1wQfQPFCd58gLHq5di+TCbjHCTJoITnAIGch/BeKxfvE64JkQI6sUVVoR8D2gyTn0S4DPG3A GaeDaE60de0UFn6fy1vH9aVDNNnfXRVKr4JresTWvuclGfJwMCSDrbpSZu1oQ8R42z2GxQztOKg l5HcEreBM2SqEeu4aghIW/+aXUucYNWYyEOeZHBWLrx/jxXsxW1b9RbBDOoaCPiT1nriTJIUuk+ moa9JFcrq3aUauJD9i8WuDXPCEkf42gUY94zOvhrExj+UUiRcrwpWigAFPoE+q3ZJl/F4zdfLBF hGZjg+g== X-Received: by 2002:a17:902:e94c:b0:2c8:4c29:afeb with SMTP id d9443c01a7336-2d0ca7b5520mr388297045ad.8.1786195708543; Sat, 08 Aug 2026 06:28:28 -0700 (PDT) List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Sat, 8 Aug 2026 15:27:51 +0200 X-Gm-Features: AUfX_mwGeaiLp8wdzgj5-9wgmhAZH8wveIKZFsIOihUJ8WZbcLX5Sn_lf-NKs4Q Message-ID: Subject: =?UTF-8?Q?Re=3A_Proposal_=E2=80=94_Seamless_Windows_Application_Virtua?= =?UTF-8?Q?lization_via_bhyve?= To: =?UTF-8?B?QXNpeWUgU2FyxLF5xLFsZMSxeg==?= Cc: freebsd-virtualization@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b507c00658891829" X-Rspamd-Queue-Id: 4hHMKX5qXkz3YRC X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Spamd-Bar: ---- --000000000000b507c00658891829 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I must give you some clarifications because taken by enthusiasm, I made some mistake : What I've described is essentially WinApps / WinBoat. WinApps uses FreeRDP as a backend to render Windows applications alongside Linux ones, with the host /home directory reachable inside Windows via \tsclient\home, and WinBoat exposes individual Windows program windows to the host using FreeRDP and Windows' RemoteApp protocol, avoiding the overhead of streaming an entire desktop by returning individual windows to the compositor. Nobody has built this on FreeBSD/bhyve. That gap is the actual contribution. GitHu= b Windows Forum But three parts of my sketch were wrong, and they're the load-bearing ones. *1. Looking Glass cannot give me seamless windows.* LG captures the guest's *whole framebuffer* as one surface. It has no concept of a top-level window. I would get a Windows desktop in a box =E2=80=94 exactly the VNC experience I= 'm trying to escape, just faster. The mechanism that produces "one Photoshop window on my FreeBSD desktop, no desktop behind it" is RDP *RemoteApp (RAIL)*: the guest exports each top-level window as its own surface and FreeRDP maps each one to a local X11 window. So my "without remote desktop server and client" requirement has to be restated. I *do* use RDP. I just never see a desktop. The protocol is an implementation detail; the UX is what you described. If I want to insist on literally no RDP, I have to write a RAIL-equivalent myself =E2=80=94 a gues= t agent hooking window creation, plus a host compositor client =E2=80=94 which is a multi-year project for a strictly worse result. *2. Windows cannot live in a jail or a podman container.* A jail shares the FreeBSD kernel. Podman on FreeBSD runs FreeBSD containers. dockur/windows on Linux is not containerized Windows =E2=80=94 it's a container that *wrap= s QEMU*; the isolation is the VM. On FreeBSD the sandbox is bhyve, full stop. A vnet jail is still useful, but as a wrapper around the *bhyve process* (network confinement, resource limits), not as the thing Windows runs in. *3. sshfs-win points the wrong direction, and I probably don't need it.* sshfs-win mounts *my FreeBSD* filesystem *inside Windows* =E2=80=94 that's = the useful direction, but RDP already does it for free with /drive:home,/home/marietto, appearing as \\tsclient\home, over the same connection, no WinFsp, no extra daemon. The apps then read and write my real FreeBSD files natively, which makes "access files installed inside the VM" a non-goal =E2=80=94 I never need to reach into C:\Program Files. If I = still want host=E2=86=92guest visibility, I have to run SMB in the guest and moun= t_smbfs it; do not mount the live zvol. *What the FreeBSD stack actually is* net/freerdp3 is in ports and supports /app:program:... =E2=80=94 the RAIL c= lient is done, cross-platform, already builds on FreeBSD. That's the piece that looked hardest and isn't. The rest is: - bhyve + edk2, virtio-blk on a zvol, headless, VNC only for the initial install - Win11 Pro (your own DVD/key), RemoteApp unlocked via the TSAppAllowLis= t registry keys =E2=80=94 Microsoft doesn't expose RemoteApp on client SKU= s but it works; this is what WinApps does - a thin CLI + a guest agent that enumerates Start Menu .lnk entries into a JSON manifest on the shared drive, from which the host generates shims and .desktop files install and run then become two RDP invocations: install launches the installer as a RemoteApp (or drops me into a full session for the ones that demand it), run launches the registered target. *The part that's genuinely better on FreeBSD than on Linux:* ZFS. Snapshot the zvol before every install, and uninstall becomes a rollback. Per-app clones give me real per-application sandboxes off one golden Windows dataset, at near-zero disk cost. That's a feature Wine structurally cannot have and WinApps doesn't bother with. *Where Looking Glass does fit* =E2=80=94 as a *second display path*, not th= e primary one. RAIL for normal apps; LG for fullscreen GPU-accelerated single-app mode where RDP's encode/decode latency hurts. My ivshmem-plain work isn't wasted, it's just answering a different question. Don't let this project block on it. *Honest weaknesses* - Cold start. Wine launches in ~1s; I need a warm VM. bhyve suspend/resume exists but is still experimental and requires kernel and userland rebuilt with the BHYVE_SNAPSHOT option, and has had limitations with multiple devices of the same type. Plan on a daemon holding the VM = up, first launch 30=E2=80=9360s, subsequent ~1=E2=80=932s. FreeBSD FreeBSD - GPU. Under RDP the presentation surface is encoded on the host-guest link. A passthrough GPU still serves compute (Adobe's accelerated filter= s, CUDA), but I need the "use hardware graphics adapters for all RDS sessio= ns" policy set. - Multi-monitor RAIL has known artifacts depending on compositor. *Gate 0*, before writing any CLI: bring up a headless Win11 Pro guest under bhyve, unlock RemoteApp, and get xfreerdp3 /app:program:notepad.exe /drive:home,/home/marietto to paint a single Notepad window on my FreeBSD X session that can open a file from my home directory. If that works, everything else is orchestration. If it doesn't, no amount of CLI design saves it. On Sat, Aug 8, 2026 at 3:11=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z wrote: > Hmm. Actually it's... It's true. I was overly cautious there looking at > Looking Glass's actual requirements, iGPU + dedicated GPU is officially o= ne > 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 hos= t > 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 mu= ch > 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 IS= O > to sidestep licensing, sshfs-win or a jail for file access, and now Looki= ng > 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 genuinel= y > make FreeBSD a more viable desktop choice for people who are currently > stuck on Windows just for a handful of apps > > > 8 A=C4=9Fu 2026 Cmt 14:03 tarihinde Mario Marietto > =C5=9Funu yazd=C4=B1: > >> ->The main constraint I see is GPU passthrough requirements Looking Glas= s >> typically needs >dedicated/secondary GPU (or at least IOMMU-capable >> hardware) for good performance, which not >every FreeBSD desktop user wi= ll >> 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 G= PU >> integrated inside my Aorus Pro with one Intel I9 cpu on top of it and tw= o >> 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=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z <= 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 ter= ms >>> 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 wi= ll >>> 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 pret= ty >>> complete picture. Really appreciate you connecting the dots here. >>> >>> 8 A=C4=9Fu 2026 Cmt 13:48 tarihinde Mario Marietto >>> =C5=9Funu yazd=C4=B1: >>> >>>> >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 Window= s is >>>> installed :) >>>> >>>> So nice. >>>> >>>> On Sat, Aug 8, 2026 at 2:39=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z= >>>> 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-installe= d the >>>>> user would need to download the ISO or a similar file themselves. >>>>> >>>>> 8 A=C4=9Fu 2026 Cmt 13:35 tarihinde Asiye Sar=C4=B1y=C4=B1ld=C4=B1z <= asiyee994@gmail.com> >>>>> =C5=9Funu yazd=C4=B1: >>>>> >>>>>> 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 lightwei= ght >>>>>> 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 do= es >>>>>> qemu-bhyve install adobe and interacts with the app almost like a na= tive >>>>>> FreeBSD program =E2=80=94 no manual VM management, no VNC. Your cont= ainer/jail idea >>>>>> for file access sounds like a great way to get part of that seamless= ness >>>>>> 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 kern= el >>>>>> (even a minimal one) is needed rather than translation >>>>>> >>>>>> 8 A=C4=9Fu 2026 Cmt 13:18 tarihinde Mario Marietto >>>>>> =C5=9Funu yazd=C4=B1: >>>>>> >>>>>>> >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 mod= e in >>>>>>> VirtualBox or WSLg in Linux). I thought bhyve >could achieve better= raw >>>>>>> hardware compatibility for specific professional Windows apps. Exam= ple >>>>>>> >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 alm= ost >>>>>>> intact,but I would use plane bhyve or qemu accelerated with bhyve i= nstead >>>>>>> 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 j= ail ? ). >>>>>>> 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=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4= =B1z < >>>>>>> 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 opera= ting in >>>>>>>> the background, where the GUI windows are seamlessly integrated in= to the >>>>>>>> FreeBSD desktop environment (like seamless mode in VirtualBox or W= SLg in >>>>>>>> Linux). I thought bhyve could achieve better raw hardware compatib= ility for >>>>>>>> specific professional Windows apps. Example Adobe >>>>>>>> >>>>>>>> 8 A=C4=9Fu 2026 Cmt 11:30 tarihinde Mario Marietto < >>>>>>>> marietto2008@gmail.com> =C5=9Funu yazd=C4=B1: >>>>>>>> >>>>>>>>> ---> have you tried wine11? >>>>>>>>> >>>>>>>>> I think he wants to "duplicate" the look and feel and the exterio= r >>>>>>>>> working of wine,but using bhyve at the place of wine ? Did I unde= rstand >>>>>>>>> correctly ? >>>>>>>>> >>>>>>>>> On Sat, Aug 8, 2026 at 12:17=E2=80=AFPM Tomek CEDRO >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> have you tried wine11? >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >>>>>>>>>> >>>>>>>>>> On Sat, Aug 8, 2026, 00:22 Asiye Sar=C4=B1y=C4=B1ld=C4=B1z >>>>>>>>>> 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 =E2=80= =94 creating disk >>>>>>>>>>> images, configuring UEFI/BIOS, installing drivers, and manually= managing >>>>>>>>>>> the guest OS. This works, but it's a heavy, manual process comp= ared 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 = =E2=80=94 with >>>>>>>>>>> minimal manual steps. Since the user brings their own ISO and l= icense, this >>>>>>>>>>> avoids any licensing or redistribution concerns on the project'= s side. >>>>>>>>>>> Ideally, this could eventually extend toward seamless window in= tegration >>>>>>>>>>> (running individual Windows apps like Adobe software without ex= posing the >>>>>>>>>>> full Windows desktop), similar to what VMware Fusion or Paralle= ls offer on >>>>>>>>>>> macOS. >>>>>>>>>>> I understand this raises real challenges =E2=80=94 driver signi= ng, GPU >>>>>>>>>>> passthrough for apps like Adobe's Creative Suite, and the signi= ficant >>>>>>>>>>> engineering effort seamless integration would require compared = to a >>>>>>>>>>> standard full-VM setup. >>>>>>>>>>> Is this something the core team has considered, or is it alread= y >>>>>>>>>>> covered by existing tools (e.g., vm-bhyve, or work in progress)= ? I'd >>>>>>>>>>> appreciate your perspective on whether this is a realistic dire= ction 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. >> > --=20 Mario. --000000000000b507c00658891829 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I must give you some clarifications because ta= ken by enthusiasm, I made some mistake :


What I've describe= d is essentially WinApps / WinBoat. WinApps uses FreeRDP as a backend to re= nder Windows applications alongside Linux ones, with the host /home directo= ry reachable inside Windows via \tsclient\home, and WinBoat exposes individ= ual Windows program windows to the host using FreeRDP and Windows' Remo= teApp protocol, avoiding the overhead of streaming an entire desktop by ret= urning individual windows to the compositor. Nobody has built this on FreeB= SD/bhyve. That gap is the actual contribution. GitHubWindows Forum

But three parts of my sketch were wrong, and they&#= 39;re the load-bearing ones.

1. Looking Glass cannot give me seamless wi= ndows. LG captures the guest's whole framebuffer as o= ne surface. It has no concept of a top-level window. I would get a Windows = desktop in a box =E2=80=94 exactly the VNC experience I'm trying to esc= ape, just faster. The mechanism that produces "one Photoshop window on= my FreeBSD desktop, no desktop behind it" is RDP RemoteApp (R= AIL): the guest exports each top-level window as its own surface a= nd FreeRDP maps each one to a local X11 window.

So my "without remote desktop server and clien= t" requirement has to be restated. I=C2=A0do use RDP. I just = never see a desktop. The protocol is an implementation detail; the UX is wh= at you described. If I want to insist on literally no RDP, I=C2=A0have to w= rite a RAIL-equivalent myself =E2=80=94 a guest agent hooking window creati= on, plus a host compositor client =E2=80=94 which is a multi-year project f= or a strictly worse result.

2. Windows cannot live in a jail or a podma= n container. A jail shares the FreeBSD kernel. Podman on FreeBSD r= uns FreeBSD containers. dockur/windows on Linux is not containerized Windows =E2=80=94 it= 's a container that wraps QEMU; the isolation is the VM. On Fr= eeBSD the sandbox is bhyve, full stop. A vnet jail is still useful, but as = a wrapper around the bhyve process (network confinement, resource = limits), not as the thing Windows runs in.

3. sshfs-win points the wrong direction, an= d I probably don't need it. sshfs-win mounts my FreeBSD filesystem inside Windows =E2=80=94 that's the useful direc= tion, but RDP already does it for free with /drive:home,/home/marietto, appearing as \\tsclient\home, o= ver the same connection, no WinFsp, no extra daemon. The apps then read and= write my real FreeBSD files natively, which makes "access files insta= lled inside the VM" a non-goal =E2=80=94 I never need to reach into C:\Program Files= . If I still want host=E2=86=92guest visibility, I have to run SMB in the g= uest and mount_smbfs<= /code> it; do not mount the live zvol.

What the FreeBSD stack actually is=

net/freerdp3 is in ports and supports /app:program:... =E2=80=94 the RAIL clien= t is done, cross-platform, already builds on FreeBSD. That's the piece = that looked hardest and isn't. The rest is:

  • bhyve + edk2, virtio-blk on a zvol, headless, VNC only for the i= nitial install
  • Win11 Pro (your own DVD/key), Re= moteApp unlocked via the TSAppAllowList registry keys =E2=80=94 Microsoft doesn't exp= ose RemoteApp on client SKUs but it works; this is what WinApps does
    • a thin CLI + a guest agent that enumerates Start Menu= .lnk entries = into a JSON manifest on the shared drive, from which the host generates shi= ms and .desktop files

install and run then become two RDP invocations: install launches the installer as a RemoteAp= p (or drops me into a full session for the ones that demand it), run launches the registe= red target.

The part that's genuinely better on Fre= eBSD than on Linux: ZFS. Snapshot the zvol before every install, and uninstall becomes a rollb= ack. Per-app clones give me real per-application sandboxes off one golden W= indows dataset, at near-zero disk cost. That's a feature Wine structura= lly cannot have and WinApps doesn't bother with.

Where Looking Glass does fit =E2= =80=94 as a second display path, not the primary one. RAIL for nor= mal apps; LG for fullscreen GPU-accelerated single-app mode where RDP's= encode/decode latency hurts. My ivshmem-plain work isn't wasted, it= 9;s just answering a different question. Don't let this project block o= n it.

Honest weaknesses

  • Cold start. Wine launches in ~1s; I need a warm VM. bhyve suspen= d/resume exists but is still experimental and requires kernel and userland = rebuilt with the BHYVE_SNAPSHOT option, and has had limitations with multip= le devices of the same type. Plan on a daemon holding the VM up, first laun= ch 30=E2=80=9360s, subsequent ~1=E2=80=932s. FreeBSDFreeBSD
  • GPU= . Under RDP the presentation surface is encoded on the host-guest link. A p= assthrough GPU still serves compute (Adobe's accelerated filters, CUDA)= , but I need the "use hardware graphics adapters for all RDS sessions&= quot; policy set.
  • Multi-monitor RAIL has known = artifacts depending on compositor.

Gate 0, before writing any CLI: br= ing up a headless Win11 Pro guest under bhyve, unlock RemoteApp, and get xfreerdp3 /app:program:= notepad.exe /drive:home,/home/marietto to paint a single Notepad win= dow on my FreeBSD X session that can open a file from my home directory. If= that works, everything else is orchestration. If it doesn't, no amount= of CLI design saves it.



On Sat, Aug 8, 2026 a= t 3:11=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z <asiyee994@gmail.com> wrote:
Hmm. Actually it'= ;s... It's true. I was overly cautious there=C2=A0 looking at Looking G= lass's actual requirements, iGPU + dedicated GPU is officially one of t= heir 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=C2=A0 but that's a minor tradeoff, not a blocker. = So GPU passthrough is much more broadly achievable than I gave it credit fo= r. Stepping back a bit=C2=A0 I'd love to hear what you think of where t= his thread has landed overall. Between the qemu-bhyve install/run workflow,= bringing your own Windows ISO to sidestep licensing, sshfs-win or a jail f= or file access, and now Looking Glass for near-native seamless display, it = feels like the pieces could actually fit together into something coherent.<= /div>
Do you think this is realistic to build, or are we u= nderestimating 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=C4=9Fu 2026 Cmt 14:03 tarihinde Mario Marietto <marietto2008@gmail= .com> =C5=9Funu yazd=C4=B1:
->The main constraint I see is = GPU passthrough requirements Looking Glass typically needs >dedicated/secondary GPU (or at least IOMMU-capable=20 hardware) for good performance, which not >every FreeBSD desktop user=20 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 Inte= l I9 cpu on top of it and two dedicated GPUs I use for programming. A GTX 1= 060 and one RTX 2080 ti. I think this is the common scenario for most peopl= e.=C2=A0

On Sat, Aug 8, 2026 at 2:53=E2=80=AFPM Asiye Sar= =C4=B1y=C4=B1ld=C4=B1z <asiyee994@gmail.com> wrote:
Looking Gl= ass is a brilliant addition to this idea exactly the kind of "seamles= s" experience I was hoping for, and much better than VNC in terms of l= atency. Having the client run natively on FreeBSD while the server runs ins= ide the jail/VM with Windows would make the whole thing feel like a real na= tive app rather than a remote session.
The main constraint= I see is GPU passthrough requirements Looking Glass typically needs a ded= icated/secondary GPU (or at least IOMMU-capable hardware) for good performa= nce, which not every FreeBSD desktop user will have. Maybe we could fall ba= ck to a VNC-based mode when passthrough isn't available, and use Lookin= g Glass as the "fast path" when it is.
Com= bined with the qemu-bhyve install/run workflow and sshfs-win (or a jail-bas= ed file mount) for file access, this is shaping up to be a pretty complete = picture. Really appreciate you connecting the dots here.

8 A=C4=9Fu 20= 26 Cmt 13:48 tarihinde Mario Marietto <marietto2008@gmail.com>= ; =C5=9Funu yazd=C4=B1:
>Thanks for the feedback Actually what I h= ad in mind is closer to how WSL2 works on Windows

= qemu-bhyve install Windows (and here you should insert the WIndows DVD to a= void licensing issues).
Windows will be installed inside the sand= box. Actually I like the idea to use sshfs-win

Lat= er,you can do : qemu-bhyve "tool". And again the tool will=C2=A0b= e installed inside the sandbox.

This is the perfec= t chance to port Looking Glass,with the client part which runs on FreeBSD a= nd the server part inside the jail where Windows is installed :)=C2=A0=C2= =A0

So nice.

On Sat, Aug 8, 2026 at 2:39=E2= =80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z <asiyee994@gmail.co= m> wrote:
I haven't yet considered how to resolve the licensin= g 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 th= emselves.

8 A=C4=9Fu 2026 Cmt 13:35 tarihinde Asiye Sar=C4=B1y=C4=B1ld=C4=B1= z <asiyee994@gmail.com> =C5=9Funu yazd=C4=B1:
Thank= s 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, bu= t the user never manages the VM directly=C2=A0 file sharing, networking, an= d even GUI apps (via WSLg) are fully integrated, so it feels native.
I'd love something like that for FreeBSD + Windows apps: bhy= ve running a minimal Windows VM in the background, but the user just does q= emu-bhyve install adobe and interacts with the app almost like a native Fre= eBSD program =E2=80=94 no manual VM management, no VNC. Your container/jail= idea for file access sounds like a great way to get part of that seamlessn= ess without needing full window integration.
Regular= Wine can't run Adobe or Teams reliably because of missing Win32 API co= verage, which is exactly why I think a real Windows kernel (even a minimal = one) is needed rather than translation

8 A=C4=9Fu 2026 Cmt 13:18 tarih= inde Mario Marietto <marietto2008@gmail.com> =C5=9Funu yazd=C4=B1:

=

qemu-bhyve install or run "application".=C2= =A0

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 with= out accessing inside the vm with vnc viewer,but easier,we can install a con= tainer (podman ? a jail ? ). It sounds nice to me.

ERRATA CORRIGE : we can install the desired tool directly inside a contain= er (podman ? a jail ? sshfs-win ?=C2=A0

https://forums.freebsd.org/threads/w= indows-drive-mapping-to-freebsd-directory-fails-with-sshfs-win.96474/

What do you think ?

On Sat, Aug 8, 2026 at 12:= 32=E2=80=AFPM Asiye Sar=C4=B1y=C4=B1ld=C4=B1z <asiyee994@gmail.com> wrote:
Yes, I know about Wine, but W= ine tries to replicate Windows APIs which often causes compatibility bugs o= r performance overhead. My idea with bhyve was closer to a lightweight virt= ualized Windows kernel operating in the background, where the GUI windows a= re seamlessly integrated into the FreeBSD desktop environment (like seamles= s mode in VirtualBox or WSLg in Linux). I thought bhyve could achieve bette= r raw hardware compatibility for specific professional Windows apps. Exampl= e Adobe=C2=A0

8 A=C4=9Fu 2026 Cmt 11:30 tarihinde Mario Marietto <marietto2008@gmail.com> =C5=9Funu yazd= =C4=B1:
---> have you tried wine11?

I thi= nk he wants to "duplicate" the look and feel and the exterior wor= king of wine,but using bhyve at the place of wine ? Did I understand correc= tly ?

On Sat, Aug 8, 2026 at 12:17=E2=80=AFPM Tomek CEDRO <tomek@cedro.info> wrote:
h= ave you tried wine11?

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

On Sat, Aug 8, 2026, 00:22 Asiye Sar=C4=B1y=C4=B1ld=C4=B1z <asiyee994@gmail.com> wrote:
= I've been thinking about a potential enhancement to bhyve that could ma= ke Windows application compatibility much smoother for FreeBSD desktop user= s.
Currently, running Windows applications (e.g., Adobe pr= oducts) requires manually setting up a full Windows VM in bhyve =E2=80=94 c= reating disk images, configuring UEFI/BIOS, installing drivers, and manuall= y managing the guest OS. This works, but it's a heavy, manual process c= ompared to solutions like Wine/Proton on Linux or Parallels' seamless m= ode 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 provisionin= g, NT kernel boot configuration, and required virtio/driver setup automatic= ally =E2=80=94 with minimal manual steps. Since the user brings their own I= SO 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 wit= hout exposing the full Windows desktop), similar to what VMware Fusion or P= arallels offer on macOS.
I understand this raises re= al challenges =E2=80=94 driver signing, GPU passthrough for apps like Adobe= 's Creative Suite, and the significant engineering effort seamless inte= gration 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 ap= preciate your perspective on whether this is a realistic direction for bhyv= e, 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.


--
Ma= rio.


--
Ma= rio.


--
Mario.


--
Ma= rio.


--
Ma= rio.


--
Ma= rio.
--000000000000b507c00658891829--