161–170 of 178 posts
Does this offer anything over virt-manager on Linux?
Workstation (and Fusion too I think) also provide DirectX 10 + 11 support in Windows VMs.
So if you're wanting to run software that uses that in a Windows, you'll need something like Workstation or Fusion since virt-manager can't (yet) do that.
Earlier quoted context omitted.
Today this is mostly implemented by having a guest driver pass calls through to a layer on the host that does the actual rendering. While I agree that there is a lot of magic to making such an arrangement work, it's a terrible awful idea to suggest that relying on a vendor's emulation layer is how things should be done today. Proper GPU virtualization and/or partitioning is the right way to do it and the vendors need…
So you say having a decoupled arrangement in software (which happens to be a de facto open standard) is a "terrible awful idea" and that instead you should just rely on whatever your proprietary hardware graphics vendor proposes to you? Why? And that's assuming they propose anything at all. Even GVT-g breaks every other Linux release, is at risk of being abandoned by Intel (e.g. how they already abandoned the Xen ver…
I am talking about virtualization in the sense of being able to divide the hardware resources of a system into isolated domains and give control of those resources to guest operating systems. Passing API calls from guest to host for execution inside of the host domain is not that. A GPU providing a bunch of PCIe virtual functions which are individually mapped to guests interacting directly with the hardware is that.
GPU virtualization should be the base implementation and paravirtualization/HLE/api-passthrough can still sit on top as a fast-path when the compromises of doing it that way can be justified.
I have been using Hyper-V since the early days, and run it on both my development iron (Win11 23H2, heavily castrated) as well as my personal (non-commercial) Win2k22 21H2 Datacentre servers.
Why should I choose VMware over Hyper-V?
Genuinely curious.
Proxmox is completely free to download and deploy without any cost. For commercial and personal use.
my longterm homelab of ESXi 6.x on Intel NUC with unlimited license hack recently blew up (repeated power surges, no UPS). went with Intel NUC again but proxmox instead for the rebuild and its been a dream so far. i don't miss ESXi or Vmware in general one bit.
Now go try to download it. All links are broken. https://knowledge.broadcom.com/external/article?articleNumbe... https://www.vmware.com/content/vmware/vmware-published-sites... https://customerconnect.vmware.com/web/vmware/downloads/info...
https://support.broadcom.com/group/ecx/productdownloads?subf...
Earlier quoted context omitted.
KVM will happily work with real virtual GPU support from every vendor; it's the vendors (except for intel) that feel the need to artificially limit who is allowed to use these features.
I was mostly hoping qemu would get paravirtualized support some day, because it is leagues ahead of VMware Player in speed. Everyone's hopes are riding on https://github.com/virtio-win/kvm-guest-drivers-windows/pull... .
I just think it should be the objective of vendors to offer actual GPU virtualization first and to support paravirtualization as an optimization in the cases where it is useful or superior and the tradeoffs are acceptable.
Earlier quoted context omitted.
What is the use case for using Virtualbox with Hyper-V? Why not just use Hyper-V directly?
The use case is mainly interoperability with VirtualBox; they can still keep thier own disk/vm formats, guest tools, etc. and use HyperV as the 'virtualization engine'. Users that have workflows that call out to VirtualBox can continue to work; a lot of vm image tools (vagrant, packer) continue to work, etc. But yes, of course you can also change your tools to use HyperV directly. "Having to use HyperV" is not actual…
The nefarious part is that Windows enables Hyper-V even if you don't actually use Hyper-V VMs and never will. KVM doesn't take exclusive control of VMX until you _actually_ run a KVM VM.
By the way, the distinction between type 1 / 2 is purely academic at this point: there is no definition where KVM is a type 1 hypervisor and VirtualBox isn't, as they are _literally_ the same conceptually-wise: both are a kernel module that implements a VMX manager/root. Same on Windows. The only remaining type 2 hypervisor these days is kqemu which can still work in binary translation mode (and therefore can work even without access to VMX).
Earlier quoted context omitted.
Why is the Hyper-V backend so much slower?
In truth it's not; however if the software has to do extra things like, for instance, translate io calls to a virtualbox disk format that hyperv cannot natively support or do an extra memcpy on the video framebuffer to get their UI to work then there will be necessary performance impacts. How fast a guest os "feels" is mostly down to the performance of the virtualized devices and not necessarily the overhead of virtu…
One of the reasons mentioned is that VirtualBox runs (some) emulated devices in kernel space but is not allowed to do when running with Hyper-V. The official API forces custom devices to strictly be user space, and only some basic hardcoded devices are emulated from kernel space.
The "secret sauce" of a desktop virtualizer is in part in the selection of devices it emulates, so this severely cripples VirtualBox.
Earlier quoted context omitted.
So you say having a decoupled arrangement in software (which happens to be a de facto open standard) is a "terrible awful idea" and that instead you should just rely on whatever your proprietary hardware graphics vendor proposes to you? Why? And that's assuming they propose anything at all. Even GVT-g breaks every other Linux release, is at risk of being abandoned by Intel (e.g. how they already abandoned the Xen ver…
A soft-gpu driver backed by real hardware "somewhere else" is a beautiful piece of software! While it certainly has application in virtual machines, and may even be "optimal" for some use cases like desktop gaming, it's ultimately doesn't fit with the modern definition of "virtualization -- I am talking about virtualization in the sense of being able to divide the hardware resources of a system into isolated domains…
If you want to really divide hardware resources, then as I argue in the other thread doing it in software is clearly a much more sensible way to go. You are not subject to the whims of the GPU vendor and the OS, rather than the firmware, control the partition boundaries. Same as what has been done in practically every other virtualized device (CPUs, memory, etc.). We never expected the hardware to need to partition itself; I'd even have a hard time calling that "virtualization" at all. Plus, the way hardware is designed these days, it is highly unlikely that the PCI virtual functions of a GPU function as an effective security boundary. If it wasn't for performance, using hardware partitioning would never be a worthwhile tradeoff.
Now go try to download it. All links are broken. https://knowledge.broadcom.com/external/article?articleNumbe... https://www.vmware.com/content/vmware/vmware-published-sites... https://customerconnect.vmware.com/web/vmware/downloads/info...
I spent like 15 minutes trying to find an official download link, even registered a broadcom account but that was a waste of time as well. Ended up finding a working download link from some reddit comment. It seems to contain all versions of fusion, player, workstation and remote console. https://softwareupdate.vmware.com/cds/vmw-desktop/ws/