5 ms·

I've found the performance penalty in practice to be only a few percentages, since virtualization is supported at the hardware level / HyperV. Essentially undet

I've found the performance penalty in practice to be only a few percentages, since virtualization is supported at the hardware level / HyperV. Essentially undetectable. YMMV. Parallels Desktop and/or VMware Fusion are superior (IMO) for GPU passthrough, but virtualbox can work. 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-the-same-machine/23578/7 https://forums.docker.com/t/running-docker-and-virtualbox-on... In this case, a dual-boot is a superior solution.

Nullabillity 8y ago
> 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.. https://forums.docker.com/t/running-docker-and-virtualbox-on.... 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).

Nullabillity 8y ago

> 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.. https://forums.docker.com/t/running-docker-and-virtualbox-on.... 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).