On Oct 7, 2016, at 5:14 AM, Daniel P. Berrange wrote: > On Fri, Oct 07, 2016 at 09:21:36AM +0200, Paolo Bonzini wrote: >> >> >> On 06/10/2016 22:26, Eric Blake wrote: >>>>> Doesn't virt-manager already do this? What do we gain by duplicating >>>>> GUI functionality at this level that is already implemented at higher >>>>> levels? Not that I'm opposed to the idea, but having a solid reason why >>>>> it is useful is important. >>>> >>>> Virt-manager is a Linux exclusive. This program doesn't run on Windows or >>>> Mac OS. >>> >>> Not true. I've seen it ported to Windows, and I'm sure Cole would >>> welcome a port to Mac. >> >> I don't think that included a port of libvirtd, so you'd still need a >> Linux system to run the VMs on. > > I would expect libvirtd to pretty much "just work" for the most part. > Any part of libvirt which depends on Linux specific APIs has conditional > compilation, or portability layers. OS-X is BSD underneath so majority > of functionality will trivially work - unlike windows where making libvirtd > work is very hard due to missing fork/exec paradigm. There's likely to be > gremlins hiding in the libvirt QEMU driver just because 99% of all work is > done in Linux, but we'd be more than happy with patches to fix any OS-X > portability problems.
I have actually tried to port Virt-manager and libvirt to Mac OS X. It does anything but work. Sorry to have to say this but it was a nightmare trying to make Virt-manager run. The number of dependencies involved makes installing QEMU from scratch look easy. Virt-manager is a long ways off from running in Mac OS X.
