4 ms·

QEMU is also a lovely piece of software, and completely free and open source. It lacks the graphical interface of VirtualBox, but it's more scriptable, in my o

QEMU is also a lovely piece of software, and completely free and open source. It lacks the graphical interface of VirtualBox, but it's more scriptable, in my opinion. In fact, virt-manager basically bridges the gap between VirtualBox and QEMU with the unfortunate dependency of libvirt.

jcrben 3y ago
Why is libvirt unfortunate?
- jakogut 3y ago
  Often users only want QEMU, with a graphical interface on top. Libvirt is not just a graphical interface, but also an abstraction over multiple virtualization backends. It tends to add complexity, while making more advanced usage of specific virtualization backends more difficult. Especially with its own configuration format based on XML. Edit: Correction, libvirt is not the graphical interface, but entirely the virtualization abstraction. Virt-manager one of several interfaces.
cassianoleal 3y ago
> It lacks the graphical interface of VirtualBox On macOS, UTM bridges that gap. It's also compatible with the native virtualisation stack which makes for extremely speedy VMs (boots in literally 1-2s, great performance overall - except for some lag on the GUI).
- mieses 3y ago
  I tried to run Win XP on UTM on MacOS x64 about a year ago. it worked but it was many, many, (1000x) times slower than virtualbox or parallels. I didn't want to dig into it after wasting 2 hours. internet comments indicated that UTM is slower but hid the truth of how much slower it is. UTM doesn't work.
  - cassianoleal 3y ago
    I've only run Windows (and not XP) on this a couple times so I can't comment on that much. I have run x86 Win10 on UTM on an M2 Mac and didn't have performance issues but in fairness I didn't actually do much with it - mostly accessing thumb drives formatted with NTFS. I do regularly run arm64 Linux on it though, and it's been quite stellar for that use case.
- mobiuscog 3y ago
  "great performance" is not a phrase to consider if you need to run x86 code on arm chips. Even with Rosetta 2 and the latest virtualization kit, unless you're running all arm code, it's so painfully slow. (this also applies to any mac container solutions)
  - cassianoleal 3y ago
    You can't run x86 code under the native virtualisation stack, so you're arguing against a strawman.

jcrben 3y ago

Why is libvirt unfortunate?

jakogut 3y ago
Often users only want QEMU, with a graphical interface on top. Libvirt is not just a graphical interface, but also an abstraction over multiple virtualization backends. It tends to add complexity, while making more advanced usage of specific virtualization backends more difficult. Especially with its own configuration format based on XML. Edit: Correction, libvirt is not the graphical interface, but entirely the virtualization abstraction. Virt-manager one of several interfaces.

cassianoleal 3y ago

> It lacks the graphical interface of VirtualBox On macOS, UTM bridges that gap. It's also compatible with the native virtualisation stack which makes for extremely speedy VMs (boots in literally 1-2s, great performance overall - except for some lag on the GUI).

mieses 3y ago
I tried to run Win XP on UTM on MacOS x64 about a year ago. it worked but it was many, many, (1000x) times slower than virtualbox or parallels. I didn't want to dig into it after wasting 2 hours. internet comments indicated that UTM is slower but hid the truth of how much slower it is. UTM doesn't work.
- cassianoleal 3y ago
  I've only run Windows (and not XP) on this a couple times so I can't comment on that much. I have run x86 Win10 on UTM on an M2 Mac and didn't have performance issues but in fairness I didn't actually do much with it - mostly accessing thumb drives formatted with NTFS. I do regularly run arm64 Linux on it though, and it's been quite stellar for that use case.
mobiuscog 3y ago
"great performance" is not a phrase to consider if you need to run x86 code on arm chips. Even with Rosetta 2 and the latest virtualization kit, unless you're running all arm code, it's so painfully slow. (this also applies to any mac container solutions)
- cassianoleal 3y ago
  You can't run x86 code under the native virtualisation stack, so you're arguing against a strawman.