Performance is basically native, I use it for PhotoShop and for video editing in Premiere. I was even playing with Propellorhead Reason the other day dabbling in making some music.
I'd love to do all development in Linux again but dual booting was too annoying. The way you do it sounds interesting.
Modern x86's have instruction set extensions to make VMs almost free of any overhead. The only performance hit you have is for the memory you don't allocate to the VM.
Also disk I/O. Increased disk latency can kill the VM performance, and it will increase, if the virtual disk is inside a (sparse) file, inside a filesystem.
The only other machine I have with Windows is a desktop I never turn off, so it updates itself when I'm not around.
For updates, I made it mutable, applied only the updates and made it immutable again.
(Which is too bad, because I would love to be able to stop dual booting just to be able to play some games.)
As to why someone would want to run this; there is a case where dual-boot is the only alternative : the practical difficulty, if you're a developer who runs Docker -- it doesn't play well with VirtualBox. https://forums.docker.com/t/running-docker-and-virtualbox-on...
In this case, a dual-boot is a superior solution.
Not quite. That only applies to "Docker for Windows/Mac", while a developer primarily running Linux would presumably run native Docker.
More generally, the actual problem here is that there can generally only be one hypervisor running at a time, since it grabs exclusive control of some system resources. Docker itself isn't a hypervisor, but DfW/M use the native hypervisor of their respective OS (Hyper-V and Hypervisor.Framework, respectively) to run the Linux distro boot2docker (where the actual Docker Engine is ran), and neither of those like to coexist with Virtualbox.
There is also the older Docker Toolbox (for both Windows and macOS) that used Virtualbox as its backing hypervisor, and so will happily coexist with other Vbox VMs.
But all of this is about coexisting hypervisors at the same "level". Some hypervisors (such as KVM) support nested virtualization, in which case you could run any (one) other hypervisor inside a VM managed by that hypervisor. For testing purposes I have ran DfW inside KVM, and it worked fine (if a bit slow).
However, even then the GPU's PCIe slot will need to be in a separate IOMMU group (generally only the case if it is connected directly to the CPU, bypassing the chipset, usually the case for 1-2 slots per mobo at most), which I strongly doubt Thunderbolt slots would be prioritized for.
I can do dual boot, but then I lose my dev environment, it's valuable to be able to apply a patch, compile a new version and try it on the Windows machine.
I finally gave in and ordered a Windows desktop box for testing yesterday.
And its not worth the upgrade treadmill of minor version bumps for essential features. Look no further than Linux/PowerShell that requires security turned down, and has almost no features. Its a hook to get you to use Windows.
Hard pass.